[OpenSIPS-Users] OpenSIPS Perl module branching and logging
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu May 13 20:05:31 CEST 2010
Sorry David,
never used the perl stuff and have no idea how it works :(...
Regards,
Bogdan
David Cunningham wrote:
> Thanks Bogdan.
>
> Could you give any ideas on this part of my first email?:
>
> Can anyone advise how I can (in the Perl) extract the destination
> addresses from $m as strings to verify that all the destinations are
> correct after the final $m->append_branch()?
>
>
> On Thu, May 13, 2010 at 6:09 PM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro> wrote:
>
>> Hi David,
>>
>> looking at the message, I see that the ACK is wrongly generated. The
>> RURI of the ACK must be the contact received in 200 OK (as received by
>> the phone). The 200 OK shows ast02, but the ACK goes to ast01 , which is
>> bogus.
>>
>> Also the UAC seams to ignore the RR indication - according to the RR
>> received in 200 OK, the UAC should sent the ACK to sip01 and not to
>> ast01 .....
>>
>> Regards,
>> Bogdan
>>
>> David Cunningham wrote:
>>
>>> Hi Bogdan,
>>>
>>> That sounds reasonable, but an ngrep trace on the opensips server is
>>> showing the ACK from the phone is being forwarded to the wrong
>>> Asterisk, i.e. not the one that sent the 200 OK.
>>>
>>> As I mentioned, we are passing routing of messages through a Perl
>>> module, and this branches messages to all Asterisk servers. I have
>>> logged the rewrite_ruri() and append_branch() steps so I know these
>>> are happening to all Asterisk servers.
>>> I'm therefore not sure how to determine where the fault is, given the
>>> discrepancy between the logging in the Perl code, which what we're
>>> seeing actually happen on the ngrep trace.
>>>
>>> Can you give any advice? Much appreciated!
>>>
>>>
>>> I've also copied and pasted in here the 200 OK and the ACK. You can
>>> see that ast02 sends the 200 OK to sip01, but then sip01 sends the ACK
>>> on to ast01.
>>>
>>>
>>> U 2010/05/11 08:29:01.674692 (ast02):5060 -> (sip01):5060
>>> SIP/2.0 200 OK.
>>> Via: SIP/2.0/UDP (sip01);branch=z9hG4bKd334.32c9cde4.1;received=(sip01).
>>> Via: SIP/2.0/UDP (unknown other
>>> IP):5060;rport=5060;received=(phone);branch=z9hG4bKaacc9f8227a7ea553.b59f1ab3b79f7cfcc.
>>> Record-Route: <sip:(sip01);lr=on;ftag=b9d0d92b6c>.
>>> From: "User" <sip:(calling number)@(sip01):5060>;tag=b9d0d92b6c.
>>> To: "**" <sip:**@(sip01):5060>;tag=as1a1f4c27.
>>> Call-ID: a7366e4855e295af.
>>> CSeq: 18830 INVITE.
>>> Server: Enswitch.
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO.
>>> Supported: replaces, timer.
>>> Contact: <sip:**@(ast02)>.
>>> Content-Type: application/sdp.
>>> Content-Length: 314.
>>> .
>>> v=0.
>>> o=root 1399767030 1399767030 IN IP4 (ast02).
>>> s=Asterisk PBX 1.6.1.12.
>>> c=IN IP4 (ast02).
>>> t=0 0.
>>> m=audio 12876 RTP/AVP 0 8 18 101.
>>> a=rtpmap:0 PCMU/8000.
>>> a=rtpmap:8 PCMA/8000.
>>> a=rtpmap:18 G729/8000.
>>> a=fmtp:18 annexb=no.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>> a=ptime:20.
>>> a=sendrecv.
>>>
>>>
>>>
>>> U 2010/05/11 08:29:01.984181 (sip01):5060 -> (ast01):5060
>>> ACK sip:**@(ast01):5060;transport=udp SIP/2.0.
>>> Record-Route: <sip:(sip01);lr=on;ftag=b9d0d92b6c>.
>>> Via: SIP/2.0/UDP (sip01);branch=z9hG4bKd334.32c9cde4.3.
>>> Via: SIP/2.0/UDP (unknown other
>>> IP):5060;rport=5060;received=(phone);branch=z9hG4bKc0d1abc8b8ff65c68.d1538fb17483e517f.
>>> Route: <sip:(sip01);lr=on;ftag=b9d0d92b6c>.
>>> Proxy-Require: com.nortelnetworks.firewall.
>>> Max-Forwards: 69.
>>> From: "User" <sip:(calling number)@(sip01):5060>;tag=b9d0d92b6c.
>>> To: "**" <sip:**@(sip01):5060>;tag=as1a1f4c27.
>>> Call-ID: a7366e4855e295af.
>>> CSeq: 18830 ACK.
>>> User-Agent: Aastra 57i/2.5.2.30.
>>> Content-Length: 0.
>>>
>>>
>>> On Wed, May 12, 2010 at 9:59 AM, Bogdan-Andrei Iancu
>>> <bogdan at voice-system.ro> wrote:
>>>
>>>
>>>> In such a case, from SIP point of view, there is a single ACK
>>>> corresponding to the winning branch (which sent the 200 OK).
>>>>
>>>> Regards,
>>>> Bogdan
>>>>
>>>> David Cunningham wrote:
>>>>
>>>>
>>>>> Hi Bogdan,
>>>>>
>>>>> That's correct, the ACK for the 200OK.
>>>>>
>>>>> On Wed, May 12, 2010 at 8:46 AM, Bogdan-Andrei Iancu
>>>>> <bogdan at voice-system.ro> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> David Cunningham wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> We are using OpenSIPS with a Perl module which needs to branch SIP
>>>>>>> messages to multiple Asterisk servers. This is done with a
>>>>>>> $m->rewrite_ruri() to the first destination, and an
>>>>>>> $m->append_branch() to each following destination.
>>>>>>> There's a problem though, that with ACK messages it only seems to
>>>>>>> arrive at the first Asterisk server.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> You mean the ACK for 200OK ?
>>>>>>
>>>>>> Regards,
>>>>>> Bogdan
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Does anyone know of a problem using this method to branch ACK messages?
>>>>>>>
>>>>>>> Can anyone advise how I can (in the Perl) extract the destination
>>>>>>> addresses from $m as strings to verify that all the destinations are
>>>>>>> correct after the final $m->append_branch()?
>>>>>>>
>>>>>>> Thanks for your help!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Bogdan-Andrei Iancu
>>>>>> www.voice-system.ro
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>> --
>>>> Bogdan-Andrei Iancu
>>>> www.voice-system.ro
>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Bogdan-Andrei Iancu
>> www.voice-system.ro
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
>
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list