Bug in SipURI Parser for the Contact Header

[phoenix6789]

Hi,

I ran into an interesting problem while debugging one of my call
flows. When my SUT returns a contact header in this format:

m: <sip:da...@127.0.0.1:5070;p1=123;p2=127.0.0.1:5080>

SIPr incorrectly parses the header, and the subsequent messaging that
is sent is missing the contact information. For example, the ACK has
a null R-URI. Through experimentation, I found that everything works
properly if I change my SUT contact URI format to this:

m: <sip:da...@127.0.0.1:5070;p1=123;p2=127.0.0.1>

Do you have suggestions where the bug is likely occurring or
suggestions on fixing? I've been debugging the SipUri and Session
classes looking for the likely place where this is populated.

thanks,

Dave Adams.

[phoenix6789]

I found the bug, it's in the SipURI class. The method assign() has
the following line in the parsing algorithm:

csa = hsa[0].split(COLON) #colon separated array

Unfortunately this incorrectly splits up a contact header str that has
a uri-parameter with an ipAddr & port. I double-checked the sip
syntax grammar in RFC-3261 just to make sure I wasn't doing something
non-compliant to the spec and I think what my SUT is sending is
compliant to 3261. I don't have a solution on how to fix SIPr yet.
If you have an idea on how to fix it without re-writing the whole
method please let me know.

thanks,

Dave Adams.

On Jan 18, 4:18 pm, phoenix6789 <dvad...@nortel.com> wrote:
> Hi,
>
> I ran into an interesting problem while debugging one of my call
> flows. When my SUT returns a contact header in this format:
>

>     m: <sip:d...@127.0.0.1:5070;p1=123;p2=127.0.0.1:5080>

>
> SIPr incorrectly parses the header, and the subsequent messaging that
> is sent is missing the contact information.  For example, the ACK has
> a null R-URI.  Through experimentation, I found that everything works
> properly if I change my SUT contact URI format to this:
>

>     m: <sip:d...@127.0.0.1:5070;p1=123;p2=127.0.0.1>

[sharat mohan]

Hi  Dave,

Thanks for pointing out the issue. I am looking into it.

Regards

Sharat

--
You received this message because you are subscribed to the Google Groups "Sipper" group.
To post to this group, send email to sip...@googlegroups.com.
To unsubscribe from this group, send email to sipper+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/sipper?hl=en.

[Murray Hooper]

I am trying to find a tool that is current (still active development) that will allow me to build a server case that will stay active and will depending on To: header will send back different responses.

 

Ie: To: 2125550486@sipper will respond with a correct 486 Busy response, To: 2125550404@sipper will respond with 404 Not Found response, etc.

 

Is Sippr appropropriate for this?

 

Eventually, I would like to use more of Sippr capabilities, but I need to get this up and running for proof of concept.

 

thanks

[Nasir Khan]

It is extremely easy to do what you described, with SIPr.

 

For this you will write something like this –

 

def on_invite(session)

  if session.irequest.to == “2125550486@sipper”

     session.respond_with(486)

  elsif session.irequest.to == “2125550404@sipper”

      session.respond_with(404)

  else

      session.respond_with(200)

  end

end

 

As you can see this is fairly readable and very intuitive, you just have to learn how to use session to send response, requests and how to access various headers in the request – like session.irequest.to will give you access to incoming request’s To header, session.irequest.contact will give you contact header etc.

 

SIPr is very different from other SIP testing tools in that you can do “anything” in SIPr. If there is a reasonable test case that you cannot simulate in SIPr then we will treat it as a bug and fix it.

 

Let me know if you need more help for this PoC, looking at your email address you may be just a few kilometers from me J

 

Thanks

Nasir

--