trace_dialog() is missing things

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

trace_dialog() is missing things

Jeff Pyle
trace_dialog() is missing things Hello,

In the example below, 10.1.1.1 is the caller, 10.10.10.10 is Opensips, 10.2.2.2 is the first PSTN carrier that rejects the call, and 10.3.3.3 is the second PSTN carrier that accepts the call.

In this tshark output...

1 10.1.1.1 -> 10.10.10.10  SIP/SDP Request: INVITE sip:19998887777@10.10.10.10;user=phone, with session description
2 10.10.10.10 -> 10.1.1.1 SIP Status: 100 Trying
3 10.10.10.10 -> 10.2.2.2  SIP/SDP Request: INVITE sip:9998887777@10.2.2.2;user=phone, with session description
4 10.2.2.2 -> 10.10.10.10  SIP Status: 100 Trying
5 10.2.2.2 -> 10.10.10.10  SIP Status: 503 Service Unavailable
6 10.10.10.10 -> 10.2.2.2  SIP Request: ACK sip:9998887777@10.2.2.2;user=phone
------ first carrier rejected call, try second ------
7 10.10.10.10 -> 10.3.3.3 SIP/SDP Request: INVITE sip:9998887777@10.3.3.3;user=phone, with session description
8 10.3.3.3 -> 10.10.10.10  SIP Status: 100 Trying
9 10.3.3.3 -> 10.10.10.10  SIP Status: 180 Ringing
10 10.10.10.10 -> 10.1.1.1 SIP Status: 180 Ringing
11 10.3.3.3 -> 10.10.10.10  SIP/SDP Status: 200 OK, with session description
12 10.10.10.10 -> 10.1.1.1 SIP/SDP Status: 200 OK, with session description
13 10.1.1.1 -> 10.10.10.10  SIP Request: ACK sip:9998887777@10.3.3.3
14 10.10.10.10 -> 10.3.3.3 SIP Request: ACK sip:9998887777@10.3.3.3
------ call in progress, caller hangs up ------
15 10.1.1.1 -> 10.10.10.10  SIP Request: BYE sip:9998887777@10.3.3.3
16 10.10.10.10 -> 10.3.3.3 SIP Request: BYE sip:9998887777@10.3.3.3
17 10.3.3.3 -> 10.10.10.10  SIP Status: 200 OK
18 10.10.10.10 -> 10.1.1.1 SIP Status: 200 OK

...only packets 1 and 15 are captured to the database.

Some portions of the config:

loadmodule "dialog.so"
modparam("dialog", "enable_stats", 1)
modparam("dialog", "dlg_flag", 4)
modparam("dialog", "default_timeout", 21600)
modparam("dialog", "bye_on_timeout_flag", 4)
modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
modparam("dialog", "dlg_match_mode", 1)  # 0 = DID_ONLY; 1 = DID first, SIP second
modparam("dialog", "db_url", "mysql://user:pass@localhost/database")
modparam("dialog", "db_mode", 1)
modparam("dialog", "db_update_period", 60)
modparam("dialog", "profiles_with_value", "inbound ; outbound")

loadmodule "siptrace.so"
modparam("siptrace", "db_url", "mysql://user:pass@.../database")
modparam("siptrace", "trace_on", 1)
modparam("siptrace", "enable_ack_trace", 1)

And then in route[0]:

if (is_method("INVITE")) {
        setflag(4);     # Dialog, and BYE on expiration
        if (create_dialog()){
                xlog("L_INFO", "Initial dialog successfully created\n");
                trace_dialog();
        }
        route(1);    # Process invite
}

In following advice Bogdan gave a month or two back, since I am using dialog-based tracing, I am not setting the flag.  For what it’s worth, the dialogs seem to be working properly, with the exception of the ACK-before-200-processed known issue.

I’m not sure where to go from here.  Any thoughts or hints?


Thanks,
Jeff

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trace_dialog() is missing things

Bogdan-Andrei Iancu
Hi Jeff,

Even if you use the trace_dialog() function, you still need to define
the trace_flag parameter for the module (this flag is internally used by
the functions). So, just try to define the trace_flag param:
http://www.opensips.org/html/docs/modules/devel/siptrace.html#id227228

Regards,
Bogdan

Jeff Pyle wrote:

> Hello,
>
> In the example below, 10.1.1.1 is the caller, 10.10.10.10 is Opensips,
> 10.2.2.2 is the first PSTN carrier that rejects the call, and 10.3.3.3
> is the second PSTN carrier that accepts the call.
>
> In this tshark output...
>
> 1 10.1.1.1 -> 10.10.10.10 SIP/SDP Request: INVITE
> sip:19998887777@10.10.10.10;user=phone, with session description
> 2 10.10.10.10 -> 10.1.1.1 SIP Status: 100 Trying
> 3 10.10.10.10 -> 10.2.2.2 SIP/SDP Request: INVITE
> sip:9998887777@10.2.2.2;user=phone, with session description
> 4 10.2.2.2 -> 10.10.10.10 SIP Status: 100 Trying
> 5 10.2.2.2 -> 10.10.10.10 SIP Status: 503 Service Unavailable
> 6 10.10.10.10 -> 10.2.2.2 SIP Request: ACK
> sip:9998887777@10.2.2.2;user=phone
> ------ first carrier rejected call, try second ------
> 7 10.10.10.10 -> 10.3.3.3 SIP/SDP Request: INVITE
> sip:9998887777@10.3.3.3;user=phone, with session description
> 8 10.3.3.3 -> 10.10.10.10 SIP Status: 100 Trying
> 9 10.3.3.3 -> 10.10.10.10 SIP Status: 180 Ringing
> 10 10.10.10.10 -> 10.1.1.1 SIP Status: 180 Ringing
> 11 10.3.3.3 -> 10.10.10.10 SIP/SDP Status: 200 OK, with session
> description
> 12 10.10.10.10 -> 10.1.1.1 SIP/SDP Status: 200 OK, with session
> description
> 13 10.1.1.1 -> 10.10.10.10 SIP Request: ACK sip:9998887777@10.3.3.3
> 14 10.10.10.10 -> 10.3.3.3 SIP Request: ACK sip:9998887777@10.3.3.3
> ------ call in progress, caller hangs up ------
> 15 10.1.1.1 -> 10.10.10.10 SIP Request: BYE sip:9998887777@10.3.3.3
> 16 10.10.10.10 -> 10.3.3.3 SIP Request: BYE sip:9998887777@10.3.3.3
> 17 10.3.3.3 -> 10.10.10.10 SIP Status: 200 OK
> 18 10.10.10.10 -> 10.1.1.1 SIP Status: 200 OK
>
> ...only packets 1 and 15 are captured to the database.
>
> Some portions of the config:
>
> loadmodule "dialog.so"
> modparam("dialog", "enable_stats", 1)
> modparam("dialog", "dlg_flag", 4)
> modparam("dialog", "default_timeout", 21600)
> modparam("dialog", "bye_on_timeout_flag", 4)
> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
> modparam("dialog", "dlg_match_mode", 1) # 0 = DID_ONLY; 1 = DID first,
> SIP second
> modparam("dialog", "db_url", "mysql://user:pass@localhost/database")
> modparam("dialog", "db_mode", 1)
> modparam("dialog", "db_update_period", 60)
> modparam("dialog", "profiles_with_value", "inbound ; outbound")
>
> loadmodule "siptrace.so"
> modparam("siptrace", "db_url",
> "mysql://user:[hidden email]/database" <[hidden email]/database%22>)
> modparam("siptrace", "trace_on", 1)
> modparam("siptrace", "enable_ack_trace", 1)
>
> And then in route[0]:
>
> if (is_method("INVITE")) {
> setflag(4); # Dialog, and BYE on expiration
> if (create_dialog()){
> xlog("L_INFO", "Initial dialog successfully created\n");
> trace_dialog();
> }
> route(1); # Process invite
> }
>
> In following advice Bogdan gave a month or two back, since I am using
> dialog-based tracing, I am not setting the flag. For what it’s worth,
> the dialogs seem to be working properly, with the exception of the
> ACK-before-200-processed known issue.
>
> I’m not sure where to go from here. Any thoughts or hints?
>
>
> Thanks,
> Jeff
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trace_dialog() is missing things

Jeff Pyle
Hi Bogdan,

Yep, that did it.

I was working from an email on this list you had addressed to Matteo
Marzuola on 5-Mar this year at 15:26 GMT instructing him to do not define or
use trace_flag when using trace_dialog().  Unfortunately I can't find a web
link to an archived version of the message...

Anyway, all is well.  Thanks.


- Jeff



On 3/10/09 8:39 AM, "Bogdan-Andrei Iancu" <[hidden email]> wrote:

> Hi Jeff,
>
> Even if you use the trace_dialog() function, you still need to define
> the trace_flag parameter for the module (this flag is internally used by
> the functions). So, just try to define the trace_flag param:
> http://www.opensips.org/html/docs/modules/devel/siptrace.html#id227228
>
> Regards,
> Bogdan
>
> Jeff Pyle wrote:
>> Hello,
>>
>> In the example below, 10.1.1.1 is the caller, 10.10.10.10 is Opensips,
>> 10.2.2.2 is the first PSTN carrier that rejects the call, and 10.3.3.3
>> is the second PSTN carrier that accepts the call.
>>
>> In this tshark output...
>>
>> 1 10.1.1.1 -> 10.10.10.10 SIP/SDP Request: INVITE
>> sip:19998887777@10.10.10.10;user=phone, with session description
>> 2 10.10.10.10 -> 10.1.1.1 SIP Status: 100 Trying
>> 3 10.10.10.10 -> 10.2.2.2 SIP/SDP Request: INVITE
>> sip:9998887777@10.2.2.2;user=phone, with session description
>> 4 10.2.2.2 -> 10.10.10.10 SIP Status: 100 Trying
>> 5 10.2.2.2 -> 10.10.10.10 SIP Status: 503 Service Unavailable
>> 6 10.10.10.10 -> 10.2.2.2 SIP Request: ACK
>> sip:9998887777@10.2.2.2;user=phone
>> ------ first carrier rejected call, try second ------
>> 7 10.10.10.10 -> 10.3.3.3 SIP/SDP Request: INVITE
>> sip:9998887777@10.3.3.3;user=phone, with session description
>> 8 10.3.3.3 -> 10.10.10.10 SIP Status: 100 Trying
>> 9 10.3.3.3 -> 10.10.10.10 SIP Status: 180 Ringing
>> 10 10.10.10.10 -> 10.1.1.1 SIP Status: 180 Ringing
>> 11 10.3.3.3 -> 10.10.10.10 SIP/SDP Status: 200 OK, with session
>> description
>> 12 10.10.10.10 -> 10.1.1.1 SIP/SDP Status: 200 OK, with session
>> description
>> 13 10.1.1.1 -> 10.10.10.10 SIP Request: ACK sip:9998887777@10.3.3.3
>> 14 10.10.10.10 -> 10.3.3.3 SIP Request: ACK sip:9998887777@10.3.3.3
>> ------ call in progress, caller hangs up ------
>> 15 10.1.1.1 -> 10.10.10.10 SIP Request: BYE sip:9998887777@10.3.3.3
>> 16 10.10.10.10 -> 10.3.3.3 SIP Request: BYE sip:9998887777@10.3.3.3
>> 17 10.3.3.3 -> 10.10.10.10 SIP Status: 200 OK
>> 18 10.10.10.10 -> 10.1.1.1 SIP Status: 200 OK
>>
>> ...only packets 1 and 15 are captured to the database.
>>
>> Some portions of the config:
>>
>> loadmodule "dialog.so"
>> modparam("dialog", "enable_stats", 1)
>> modparam("dialog", "dlg_flag", 4)
>> modparam("dialog", "default_timeout", 21600)
>> modparam("dialog", "bye_on_timeout_flag", 4)
>> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
>> modparam("dialog", "dlg_match_mode", 1) # 0 = DID_ONLY; 1 = DID first,
>> SIP second
>> modparam("dialog", "db_url", "mysql://user:pass@localhost/database")
>> modparam("dialog", "db_mode", 1)
>> modparam("dialog", "db_update_period", 60)
>> modparam("dialog", "profiles_with_value", "inbound ; outbound")
>>
>> loadmodule "siptrace.so"
>> modparam("siptrace", "db_url",
>> "mysql://user:[hidden email]/database" <[hidden email]/database%22>)
>> modparam("siptrace", "trace_on", 1)
>> modparam("siptrace", "enable_ack_trace", 1)
>>
>> And then in route[0]:
>>
>> if (is_method("INVITE")) {
>> setflag(4); # Dialog, and BYE on expiration
>> if (create_dialog()){
>> xlog("L_INFO", "Initial dialog successfully created\n");
>> trace_dialog();
>> }
>> route(1); # Process invite
>> }
>>
>> In following advice Bogdan gave a month or two back, since I am using
>> dialog-based tracing, I am not setting the flag. For what it¹s worth,
>> the dialogs seem to be working properly, with the exception of the
>> ACK-before-200-processed known issue.
>>
>> I¹m not sure where to go from here. Any thoughts or hints?
>>
>>
>> Thanks,
>> Jeff
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> [hidden email]
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>  
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trace_dialog() is missing things

Bogdan-Andrei Iancu
Hi Jeff,

You mean this email
http://lists.opensips.org/pipermail/users/2009-March/003611.html  ?

Well, please note there are 2 ways of triggering siptracing:
    1) by setting the flag
    2) by setting the user AVP

In Matteo's case I wasn't sure what scenario he has.

trace_dialog() can work in both cases:
    1) define the flag and call trace_dialog()  (no need to set the flag
actually)
    2) set the user AVP and call trace_dialog()

Let me know if it is clear for you.

Regards,
Bogdan

Jeff Pyle wrote:

> Hi Bogdan,
>
> Yep, that did it.
>
> I was working from an email on this list you had addressed to Matteo
> Marzuola on 5-Mar this year at 15:26 GMT instructing him to do not define or
> use trace_flag when using trace_dialog().  Unfortunately I can't find a web
> link to an archived version of the message...
>
> Anyway, all is well.  Thanks.
>
>
> - Jeff
>
>
>
> On 3/10/09 8:39 AM, "Bogdan-Andrei Iancu" <[hidden email]> wrote:
>
>  
>> Hi Jeff,
>>
>> Even if you use the trace_dialog() function, you still need to define
>> the trace_flag parameter for the module (this flag is internally used by
>> the functions). So, just try to define the trace_flag param:
>> http://www.opensips.org/html/docs/modules/devel/siptrace.html#id227228
>>
>> Regards,
>> Bogdan
>>
>> Jeff Pyle wrote:
>>    
>>> Hello,
>>>
>>> In the example below, 10.1.1.1 is the caller, 10.10.10.10 is Opensips,
>>> 10.2.2.2 is the first PSTN carrier that rejects the call, and 10.3.3.3
>>> is the second PSTN carrier that accepts the call.
>>>
>>> In this tshark output...
>>>
>>> 1 10.1.1.1 -> 10.10.10.10 SIP/SDP Request: INVITE
>>> sip:19998887777@10.10.10.10;user=phone, with session description
>>> 2 10.10.10.10 -> 10.1.1.1 SIP Status: 100 Trying
>>> 3 10.10.10.10 -> 10.2.2.2 SIP/SDP Request: INVITE
>>> sip:9998887777@10.2.2.2;user=phone, with session description
>>> 4 10.2.2.2 -> 10.10.10.10 SIP Status: 100 Trying
>>> 5 10.2.2.2 -> 10.10.10.10 SIP Status: 503 Service Unavailable
>>> 6 10.10.10.10 -> 10.2.2.2 SIP Request: ACK
>>> sip:9998887777@10.2.2.2;user=phone
>>> ------ first carrier rejected call, try second ------
>>> 7 10.10.10.10 -> 10.3.3.3 SIP/SDP Request: INVITE
>>> sip:9998887777@10.3.3.3;user=phone, with session description
>>> 8 10.3.3.3 -> 10.10.10.10 SIP Status: 100 Trying
>>> 9 10.3.3.3 -> 10.10.10.10 SIP Status: 180 Ringing
>>> 10 10.10.10.10 -> 10.1.1.1 SIP Status: 180 Ringing
>>> 11 10.3.3.3 -> 10.10.10.10 SIP/SDP Status: 200 OK, with session
>>> description
>>> 12 10.10.10.10 -> 10.1.1.1 SIP/SDP Status: 200 OK, with session
>>> description
>>> 13 10.1.1.1 -> 10.10.10.10 SIP Request: ACK sip:9998887777@10.3.3.3
>>> 14 10.10.10.10 -> 10.3.3.3 SIP Request: ACK sip:9998887777@10.3.3.3
>>> ------ call in progress, caller hangs up ------
>>> 15 10.1.1.1 -> 10.10.10.10 SIP Request: BYE sip:9998887777@10.3.3.3
>>> 16 10.10.10.10 -> 10.3.3.3 SIP Request: BYE sip:9998887777@10.3.3.3
>>> 17 10.3.3.3 -> 10.10.10.10 SIP Status: 200 OK
>>> 18 10.10.10.10 -> 10.1.1.1 SIP Status: 200 OK
>>>
>>> ...only packets 1 and 15 are captured to the database.
>>>
>>> Some portions of the config:
>>>
>>> loadmodule "dialog.so"
>>> modparam("dialog", "enable_stats", 1)
>>> modparam("dialog", "dlg_flag", 4)
>>> modparam("dialog", "default_timeout", 21600)
>>> modparam("dialog", "bye_on_timeout_flag", 4)
>>> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
>>> modparam("dialog", "dlg_match_mode", 1) # 0 = DID_ONLY; 1 = DID first,
>>> SIP second
>>> modparam("dialog", "db_url", "mysql://user:pass@localhost/database")
>>> modparam("dialog", "db_mode", 1)
>>> modparam("dialog", "db_update_period", 60)
>>> modparam("dialog", "profiles_with_value", "inbound ; outbound")
>>>
>>> loadmodule "siptrace.so"
>>> modparam("siptrace", "db_url",
>>> "mysql://user:[hidden email]/database" <[hidden email]/database%22>)
>>> modparam("siptrace", "trace_on", 1)
>>> modparam("siptrace", "enable_ack_trace", 1)
>>>
>>> And then in route[0]:
>>>
>>> if (is_method("INVITE")) {
>>> setflag(4); # Dialog, and BYE on expiration
>>> if (create_dialog()){
>>> xlog("L_INFO", "Initial dialog successfully created\n");
>>> trace_dialog();
>>> }
>>> route(1); # Process invite
>>> }
>>>
>>> In following advice Bogdan gave a month or two back, since I am using
>>> dialog-based tracing, I am not setting the flag. For what it¹s worth,
>>> the dialogs seem to be working properly, with the exception of the
>>> ACK-before-200-processed known issue.
>>>
>>> I¹m not sure where to go from here. Any thoughts or hints?
>>>
>>>
>>> Thanks,
>>> Jeff
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Users mailing list
>>> [hidden email]
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>  
>>>      
>
>
>  


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: trace_dialog() is missing things

Jeff Pyle
Hi Bogdan,

Nope, this one:  
http://lists.opensips.org/pipermail/users/2009-March/003620.html

What you're saying makes sense.  It's all good, as they say.


- Jeff



On 3/10/09 3:15 PM, "Bogdan-Andrei Iancu" <[hidden email]> wrote:

> Hi Jeff,
>
> You mean this email
> http://lists.opensips.org/pipermail/users/2009-March/003611.html  ?
>
> Well, please note there are 2 ways of triggering siptracing:
>     1) by setting the flag
>     2) by setting the user AVP
>
> In Matteo's case I wasn't sure what scenario he has.
>
> trace_dialog() can work in both cases:
>     1) define the flag and call trace_dialog()  (no need to set the flag
> actually)
>     2) set the user AVP and call trace_dialog()
>
> Let me know if it is clear for you.
>
> Regards,
> Bogdan
>
> Jeff Pyle wrote:
>> Hi Bogdan,
>>
>> Yep, that did it.
>>
>> I was working from an email on this list you had addressed to Matteo
>> Marzuola on 5-Mar this year at 15:26 GMT instructing him to do not define or
>> use trace_flag when using trace_dialog().  Unfortunately I can't find a web
>> link to an archived version of the message...
>>
>> Anyway, all is well.  Thanks.
>>
>>
>> - Jeff
>>
>>
>>
>> On 3/10/09 8:39 AM, "Bogdan-Andrei Iancu" <[hidden email]> wrote:
>>
>>  
>>> Hi Jeff,
>>>
>>> Even if you use the trace_dialog() function, you still need to define
>>> the trace_flag parameter for the module (this flag is internally used by
>>> the functions). So, just try to define the trace_flag param:
>>> http://www.opensips.org/html/docs/modules/devel/siptrace.html#id227228
>>>
>>> Regards,
>>> Bogdan
>>>
>>> Jeff Pyle wrote:
>>>    
>>>> Hello,
>>>>
>>>> In the example below, 10.1.1.1 is the caller, 10.10.10.10 is Opensips,
>>>> 10.2.2.2 is the first PSTN carrier that rejects the call, and 10.3.3.3
>>>> is the second PSTN carrier that accepts the call.
>>>>
>>>> In this tshark output...
>>>>
>>>> 1 10.1.1.1 -> 10.10.10.10 SIP/SDP Request: INVITE
>>>> sip:19998887777@10.10.10.10;user=phone, with session description
>>>> 2 10.10.10.10 -> 10.1.1.1 SIP Status: 100 Trying
>>>> 3 10.10.10.10 -> 10.2.2.2 SIP/SDP Request: INVITE
>>>> sip:9998887777@10.2.2.2;user=phone, with session description
>>>> 4 10.2.2.2 -> 10.10.10.10 SIP Status: 100 Trying
>>>> 5 10.2.2.2 -> 10.10.10.10 SIP Status: 503 Service Unavailable
>>>> 6 10.10.10.10 -> 10.2.2.2 SIP Request: ACK
>>>> sip:9998887777@10.2.2.2;user=phone
>>>> ------ first carrier rejected call, try second ------
>>>> 7 10.10.10.10 -> 10.3.3.3 SIP/SDP Request: INVITE
>>>> sip:9998887777@10.3.3.3;user=phone, with session description
>>>> 8 10.3.3.3 -> 10.10.10.10 SIP Status: 100 Trying
>>>> 9 10.3.3.3 -> 10.10.10.10 SIP Status: 180 Ringing
>>>> 10 10.10.10.10 -> 10.1.1.1 SIP Status: 180 Ringing
>>>> 11 10.3.3.3 -> 10.10.10.10 SIP/SDP Status: 200 OK, with session
>>>> description
>>>> 12 10.10.10.10 -> 10.1.1.1 SIP/SDP Status: 200 OK, with session
>>>> description
>>>> 13 10.1.1.1 -> 10.10.10.10 SIP Request: ACK sip:9998887777@10.3.3.3
>>>> 14 10.10.10.10 -> 10.3.3.3 SIP Request: ACK sip:9998887777@10.3.3.3
>>>> ------ call in progress, caller hangs up ------
>>>> 15 10.1.1.1 -> 10.10.10.10 SIP Request: BYE sip:9998887777@10.3.3.3
>>>> 16 10.10.10.10 -> 10.3.3.3 SIP Request: BYE sip:9998887777@10.3.3.3
>>>> 17 10.3.3.3 -> 10.10.10.10 SIP Status: 200 OK
>>>> 18 10.10.10.10 -> 10.1.1.1 SIP Status: 200 OK
>>>>
>>>> ...only packets 1 and 15 are captured to the database.
>>>>
>>>> Some portions of the config:
>>>>
>>>> loadmodule "dialog.so"
>>>> modparam("dialog", "enable_stats", 1)
>>>> modparam("dialog", "dlg_flag", 4)
>>>> modparam("dialog", "default_timeout", 21600)
>>>> modparam("dialog", "bye_on_timeout_flag", 4)
>>>> modparam("dialog", "dlg_extra_hdrs", "Hint: dialog expired\r\n")
>>>> modparam("dialog", "dlg_match_mode", 1) # 0 = DID_ONLY; 1 = DID first,
>>>> SIP second
>>>> modparam("dialog", "db_url", "mysql://user:pass@localhost/database")
>>>> modparam("dialog", "db_mode", 1)
>>>> modparam("dialog", "db_update_period", 60)
>>>> modparam("dialog", "profiles_with_value", "inbound ; outbound")
>>>>
>>>> loadmodule "siptrace.so"
>>>> modparam("siptrace", "db_url",
>>>> "mysql://user:[hidden email]/database" <[hidden email]/database%22>)
>>>> modparam("siptrace", "trace_on", 1)
>>>> modparam("siptrace", "enable_ack_trace", 1)
>>>>
>>>> And then in route[0]:
>>>>
>>>> if (is_method("INVITE")) {
>>>> setflag(4); # Dialog, and BYE on expiration
>>>> if (create_dialog()){
>>>> xlog("L_INFO", "Initial dialog successfully created\n");
>>>> trace_dialog();
>>>> }
>>>> route(1); # Process invite
>>>> }
>>>>
>>>> In following advice Bogdan gave a month or two back, since I am using
>>>> dialog-based tracing, I am not setting the flag. For what it¹s worth,
>>>> the dialogs seem to be working properly, with the exception of the
>>>> ACK-before-200-processed known issue.
>>>>
>>>> I¹m not sure where to go from here. Any thoughts or hints?
>>>>
>>>>
>>>> Thanks,
>>>> Jeff
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> [hidden email]
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>  
>>>>      
>>
>>
>>  
>


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users