[Users] BYE method accompanied by error
Brandon Price
brandon.price at hostrocket.com
Tue Oct 11 20:05:54 CEST 2005
I also want to make sure I include relevant portions of the openser.cfg
{
if (method=="INVITE" && uri =~ "sip:1[0-9]{10}@.*"){
if (is_user_in("From", "ld")){
if (!www_authorize("", "subscriber")){
www_challenge("", "1");
break;
if (client_nat_test("4")) {
fix_contact();
};
append_rpid_hf();
};
if (search("From: Anonymous.*")){
append_rpid_hf("", ";privacy=full");
};
setflag(1);
consume_credentials();
if (lookup("location")) {
# if found,lookup aliases and forward there...
lookup("aliases");
t_relay();
exit;
} else {
prefix("+");
rewritehost("our.pstn.gw.ip");
};
};
};
if (method=="BYE" || method=="CANCEL"){
setflag(1); #accounting flag
t_relay();
exit;
};
On Oct 11, 2005, at 12:39 PM, Klaus Darilion wrote:
> looks like a dialog matching problem. for further inspection
> complete SIP dums would be necessary:
> ngrep port 5060
>
> klaus
>
> Brandon Price wrote:
>
>> I find that I am having the same error, although with me it only
>> happens when the sip client is natted and the bye comes from the
>> pstn end. Sample tethereal capture below. I can only assume this
>> has something to do with the nat module which I am currently not
>> using yet but plan to try again to implement today.
>> 48.022862 216.120.255.29 -> 8.11.1.7 SIP/SDP Request: INVITE
>> sip: 15187278584 at ser1.manhattan.vtnoc.net, with session description
>> 48.026850 8.11.1.7 -> 216.120.255.29 SIP Status: 100 trying
>> -- your call is important to us
>> 48.027059 8.11.1.7 -> oursippproxy.net SIP/SDP Request:
>> INVITE sip:+15187278584 at oursippproxy.net, with session description
>> 48.096933 oursippproxy.net -> 8.11.1.7 SIP Status: 100 Trying
>> 49.299563 oursippproxy.net -> 8.11.1.7 SIP/SDP Status: 183
>> Session Progress, with session description
>> 49.300461 8.11.1.7 -> 216.120.255.29 SIP/SDP Status: 183
>> Session Progress, with session description
>> 56.407921 oursippproxy.net -> 8.11.1.7 SIP/SDP Status: 200
>> OK, with session description
>> 56.409252 8.11.1.7 -> 216.120.255.29 SIP/SDP Status: 200 OK,
>> with session description
>> 56.428281 216.120.255.29 -> 8.11.1.7 SIP Request: ACK
>> sip:oursippproxy.net:5060;transport=udp
>> 56.464595 8.11.1.7 -> oursippproxy.net SIP Request: ACK
>> sip:oursippproxy.net:5060;transport=udp
>> 61.956533 oursippproxy.net -> 8.11.1.7 SIP Request: BYE sip:
>> 15184782411 at 216.120.255.29:5060
>> 61.957965 8.11.1.7 -> 216.120.255.29 SIP Request: BYE sip:
>> 15184782411 at 216.120.255.29:5060
>> 61.987385 216.120.255.29 -> 8.11.1.7 SIP Status: 481 Call Leg/
>> Transaction Does Not Exist
>> 62.017630 8.11.1.7 -> oursippproxy.net SIP Status: 481 Call
>> Leg/ Transaction Does Not Exist
>> On Oct 11, 2005, at 7:35 AM, Iqbal wrote:
>>
>>> Can you check to see if you have already received a BYE for that
>>> call, some phones I had were sending there own Bye's after the GW
>>> had
>>>
>>> Iqbal
>>>
>>> Sam Lee wrote:
>>>
>>>
>>>
>>>> Hi all,
>>>> I would like to know why does my BYE method are always replied
>>>> with a 'Call Leg/Transaction does not exist' . How do they
>>>> compare whether the transaction in the BYE method exist or
>>>> not ? ( tag? ftag ? ) Are there any thing in the config that
>>>> might cause this kind of problem ? Just want to highlight that
>>>> all the calls are made in a good condition, everything except
>>>> when the call is ending.
>>>>
>>>> Please let me know if you dont understand.
>>>> Regards,
>>>> Sam
>>>>
>>>> -------------------------------------------------------------------
>>>> -- ---
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>
>
More information about the Users
mailing list