#287 Missing URI parameters in Route header of Notify

1.6.x
closed-fixed
core (110)
8
2010-05-28
2010-05-11
Benixon-Starent
No

Hi

Some of the URI parameters sent in the Record route header of initial Subscribe request is missing in the subsequent Notify Requests Route header. These parameters are fine in the 200 OK Response

SUBSCRIBE sip:s3-1@192.168.126.1 SIP/2.0
Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+428eca86ca4d48ae27433d820a8c4ff82+c48ae599257496920c81e544fc32263b+1;X-ST-CID=20003
Via: SIP/2.0/UDP 192.168.126.151:40000;branch=z9hG4bK-c3-16844359250
P-Charging-Vector: icid-value=c3-1-80-192.168.126.1
Route: <sip:10.6.9.215:4343;lr>
Expires: 440
Event: presence
Accept: application/pidf+xml
From: sip:c3-1@192.168.126.1;tag=227409984
To: sip:s3-1@192.168.126.1
P-Asserted-Identity: <sip:c3-1@192.168.126.1:5060>
>> Record-Route: <sip:6841@192.168.126.1:50602;lr>;X-ST-CID=20003;X-DC-TM-IDX=1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
>> Record-Route: <sip:6841@192.168.126.1:50602;lr;comp=sigcomp>;X-DC-TM-IDX=1;X-ST-DLG-ID=536870911 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
Call-ID: c3-1-80
CSeq: 2 SUBSCRIBE
Contact: <sip:c3-1@192.168.126.151:40000>
Content-Length: 0
Max-Forwards: 69

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.126.1:50602;branch=z9hG4bK+428eca86ca4d48ae27433d820a8c4ff82+c48ae599257496920c81e544fc32263b+1;X-ST-CID=20003
Via: SIP/2.0/UDP 192.168.126.151:40000;branch=z9hG4bK-c3-16844359250
From: sip:c3-1@192.168.126.1;tag=227409984
To: sip:s3-1@192.168.126.1;tag=63a3a7656d99041e8a54306d9877fcc5-7eba
>> Record-Route: <sip:6841@192.168.126.1:50602;lr>;X-ST-CID=20003;X-DC-TM-IDX=1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>.
>> Record-Route: <sip:6841@192.168.126.1:50602;lr;comp=sigcomp>;X-DC-TM-IDX=1;X-ST-DLG-ID=536870911 >>>>>>>>>>>>>>>>>>>>>>>>>>
Call-ID: c3-1-80
CSeq: 2 SUBSCRIBE
Expires: 440
Contact: <sip:10.6.9.215:4343>
Server: OpenSIPS (1.6.2-notls (i386/linux))
Content-Length: 0

NOTIFY sip:c3-1@192.168.126.151:40000 SIP/2.0
Via: SIP/2.0/UDP 10.6.9.215:4343;branch=z9hG4bKe845.60dde8b.0
To: <sip:c3-1@192.168.126.1>;tag=227409984
From: <sip:s3-1@192.168.126.1>;tag=63a3a7656d99041e8a54306d9877fcc5-7eba
CSeq: 1 NOTIFY
Call-ID: c3-1-80
>> Route: <sip:6841@192.168.126.1:50602;lr>;X-ST-CID=20003,<sip:6841@192.168.126.1:50602;lr;comp=sigcomp>;X-DC-TM-IDX=1 >>>>>>>>>>>>>>>>>>>>>>>
Content-Length: 0
User-Agent: OpenSIPS (1.6.2-notls (i386/linux))
Max-Forwards: 70
Event: presence
Contact: <sip:10.6.9.215:4343>
Subscription-State: active;expires=440

Discussion

  • Hi,

    I have found the cause for this problem. This is because of the following changeset,

    Revision 5760 - (view) (download) (annotate) - [select for diffs]
    Modified Tue Jun 2 09:02:06 2009 UTC (11 months, 1 week ago) by bogdan_iancu
    Original Path: trunk/parser/parse_param.c
    File length: 10985 byte(s)
    Diff to previous 4472

    - keep the list of contact params in the same order as in the header

    http://opensips.svn.sourceforge.net/viewvc/opensips?view=rev&revision=5760

    The "do_parse_rr_body" calculates the length of the record-route relying on the fact that the param_t structure returned to it inside the rr_t structure is the last parameter. But since now this has been changed to return the first parameter the length calculated accommodates only the first parameter. And the rest of the parameters are neglected.

    Possible solution could be that the length calculation in "do_parse_rr_body" be changed to reflect the length properly.

    Thanks,
    Benixon

     
    • priority: 5 --> 8
    • assigned_to: nobody --> bogdan_iancu
    • status: open --> open-accepted
     
  • Hi Benixon,

    Thanks for the report and for the hint - I will take care of this.

    Regards,
    Bogdan

     
  • param patch

     
    Attachments
  • I just uploaded here a patch - could you please test it ?

    Thanks and regards,
    Bogdan

     
    • status: open-accepted --> open-fixed
     
  • Hi Bogdan,

    I have tested the patch and it is working fine now.

    I think it might also be needed to check for other places where "parse_params" is used to make sure that there are no other issues caused.

    BTW, I was just wondering if opensips does any processing on the parameters of the Record-route header?

    If it doesn't don't you think that it is an overhead to parse these parameters. Won't it be just sufficient if we could just find the length of the entire record-route.

    Thanks and regards,
    Benixon

     
  • Thanks for testing - I uploaded the patch on SVN.

    The Route params are used by opensipsn (for example to see if it is strict or loose route - lr param, for double routing - r2 param, etc) Also other modules do use RR / Route params for storing data there.

    Regards,
    Bogda

     
    • status: open-fixed --> closed-fixed