Hi Vladimir, first of all many thanks for spending your time with doing the test! This kind of input is really valuable for us all, and especially anything that's related to conformance is guaranteed to get my attention. Please see more comments inline. Hozjan Vladimir wrote: > Hi Benny! > > I made conformance testing with konformance testing tool, and found > behaviour that is not as it should be accordingly to RFCs. Intention of > this letter is to inform you about the results. I tested released > version 0.7.0 of pjsua, so some errors could be corrected by now. Although I can't remember any fixes related to these tests, it would be great to have the test against the latest SVN trunk version, to make it more relevant. > And the results: > *1. No reply to BYE with escaped sip uri. Session was made without > escaped characters.* > Example: > INVITE sip:701069 at 172.18.80.69;transport=udp SIP/2.0 > Via: SIP/2.0/UDP > 172.18.81.26:5060;rport;branch=z9hG4bKPj00290000518e5f9d45ea > Max-Forwards: 70 > From: "Sip" <sip:701026@172.18.80.69>;tag=00290000518c5f9d45ea > To: sip:*701069*@172.18.80.69 > Contact: "Sip" <sip:701026 at 172.18.81.26:5060;transport=UDP> > Call-ID: 00290000518d5f9d45ea > CSeq: 1422475148 INVITE > Allow: INVITE, ACK, BYE, CANCEL, SUBSCRIBE, NOTIFY, REFER, OPTIONS, INFO > Supported: norefersub, 100rel > Content-Type: application/sdp > Content-Length: 313 > > v=0 > o=- 3397801224 3397801224 IN IP4 172.18.81.26 > s=pjmedia > c=IN IP4 172.18.81.26 > t=0 0 > m=audio 16384 RTP/AVP 8 0 4 96 97 98 18 > a=rtpmap:8 PCMA/8000 > a=rtpmap:0 PCMU/8000 > a=rtpmap:4 G723/8000 > a=rtpmap:96 G726-32/8000 > a=rtpmap:97 G726-40/8000 > a=rtpmap:98 G726-24/8000 > a=rtpmap:18 G729/8000 > a=sendrecv > > ... > > BYE sip:701026 at 172.18.81.26:5060 SIP/2.0 > Call-ID: 00290000518d5f9d45ea > CSeq: 1422475148 INVITE > From: <sip*:%37%30%31%30%36%39*@172.18.80.69>;tag=4483 > To: Sip <sip:701026 at 172.18.80.69>;tag=00290000518c5f9d45ea > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK6999 > Max-Forwards: 70 > Content-Length: 0 What kind of reply does it expect? Or didn't pjsip reply at all? For requests within dialog, pjsip ignores the URI parts of the From and To header, and it just concerns about the tags. As long as the tags match the dialog, the request will be accepted and responded, no matter what the user part of the URI is. > *2. No reply to unknown method in message. 405 "Method Not Allowed" > expected. > *Example: > *UNKNOWN* sip:701026 at 172.18.80.37 SIP/2.0 > Call-ID: 4613 at 172.18.81.26 > CSeq: 48 UNKNOWN > From: <sip:701069@172.18.80.37>;tag=8924 > To: <sip:701026 at 172.18.80.37> > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK6967 > Contact: sip:701069 at 172.18.80.69:5060;transport=UDP > Max-Forwards: 70 > Content-Length: 0 This is true, and this is not pjsip's fault but rather application's (pjsua) fault. As a stack, pjsip does not handle any requests outside dialog; it simply just forwards these requests to application and let application do something about it (create dialog, create UAS transaction, respond statelessly, etc.). So it is application's responsibility to reject any requests that it can't handle. > *3. INVITE with missing Call-ID doesn't produce 400 Bad Request.* > Example: > INVITE sip:701026 at 172.18.80.37 SIP/2.0 > Contact: <sip:701069 at 172.18.80.69:5060;transport=UDP> > CSeq: 69 INVITE > From: <sip:701069@172.18.80.37>;tag=8860 > Max-Forwards: 70 > To: <sip:701026 at 172.18.80.37> > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK6628 True. But from what I understand, the standard only tells us to do our best when receiving requests with missing mandatory headers. Since some bad requests cannot be responded at all (for example when the Via header is missing), the standard allows SIP implementations to just drop the bad request. So rather than trying to do too hard with handling these broken request, I think it's quite okay to just drop them. The other endpoint is just too broken to do something about. :) > *4. Incorrect value of Content-Length in INVITE doesn't produce 400 "Bad > request" reply. When the incorrect Content-Length in 200K ACK should not > be send. > *Example: > INVITE sip:701026 at 172.18.80.37 SIP/2.0 > Call-ID: 6139 at 172.18.81.26 > Contact: <sip:701069 at 172.18.80.69:5060;transport=UDP> > Content-Disposition: session > Content-Length: *160* > Content-Type: application/sdp > CSeq: 71 INVITE > From: <sip:701069@172.18.80.37>;tag=8199 > Max-Forwards: 70 > To: <sip:701026 at 172.18.80.37> > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK5113 > > v=0 > o=voicesession 12345 12345 IN IP4 193.174.154.20 > s=Voice Session > c=IN IP4 195.174.154.20 > t=0 0 > m=audio 8500 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 For requests coming from datagram based transports (such as UDP), we don't need to see the Content-Length header. pjsip just ignores it and parse the datagram directly. > *5. When re-INVITE with lower CSeq from initial INVITE is send before OK > is received, 500 internal server error is expected. > *Example: > INVITE sip:701026 at 172.18.80.69 SIP/2.0 > Call-ID: 4773 at 172.18.81.26 > Contact: <sip:701069 at 172.18.80.69:5060;transport=UDP> > Content-Disposition: session > Content-Length: 150 > Content-Type: application/sdp > CSeq: *82* INVITE > From: <sip:701069@172.18.80.37>;tag=6161 > Max-Forwards: 70 > To: <sip:701026 at 172.18.80.69> > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK7446 > > v=0 > o=voicesession 12345 12345 IN IP4 193.174.154.20 > s=Voice Session > c=IN IP4 195.174.154.20 > t=0 0 > m=audio 8500 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 > > SIP/2.0 180 Ringing > Via: SIP/2.0/UDP 172.18.80.69:5060;received=172.18.80.69;branch=z9hG4bK7446 > Call-ID: 4773 at 172.18.81.26 > From:<sip:701069 at 172.18.80.37>;tag=6161 > To: <sip:701026 at 172.18.80.69>;tag=0029000000c753c5d033 > CSeq: 82 INVITE > Contact: <sip:701026 at 172.18.81.26:5060;transport=UDP> > Content-Length: 0 > > INVITE sip:701026 at 172.18.80.69 SIP/2.0 > Call-ID: 4773 at 172.18.81.26 > Contact: <sip:701069 at 172.18.80.69:5060;transport=UDP> > Content-Disposition: session > Content-Length: 140 > Content-Type: application/sdp > CSeq: *81* INVITE > From: <sip:701069@172.18.80.37>;tag=6161 > Max-Forwards: 70 > To: <sip:701026 at 172.18.80.69> > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK6715 > > v=0 > o=voicesession 12345 12345 IN IP4 127.0.0.1 > s=Voice Session > c=IN IP4 127.0.0.1 > t=0 0 > m=audio 8500 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 I'm not sure about this. RFC 3261 Section 12.2.2 indeed says that incoming request *within dialog* that has lower CSeq must be rejected with 500 (Internal Server Error). But this only applies to requests within dialog. The second INVITE above does not have To tag, so it's not a request within dialog. It's not a merged request either (Section 12.2.2.2), since the CSeq is different. So I think pjsip is allowed to accept this request. > *6. INVITE message with To-tag is not rejected with 481. > *Example: > INVITE sip:701026 at 172.18.80.69 SIP/2.0 > Call-ID: 2384 at 172.18.81.26 > Contact: <sip:701069 at 172.18.80.69:5060;transport=UDP> > Content-Disposition: session > Content-Length: 150 > Content-Type: application/sdp > CSeq: 66 INVITE > From: <sip:701069@172.18.80.37>;tag=9580 > Max-Forwards: 70 > To: <sip:701026 at 172.18.80.69>;*tag=9079 > *Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK4221 > > v=0 > o=voicesession 12345 12345 IN IP4 193.174.154.20 > s=Voice Session > c=IN IP4 195.174.154.20 > t=0 0 > m=audio 8500 RTP/AVP 0 > a=rtpmap:0 PCMU/8000 pjsip *does* respond requests with unknown To tag with 481, so I'm not sure why it didn't do that. > *7. In PJSIP message header are case sensitive. PJSIP doesn't support > header "FrOM" of "ViA".* > Example > BYE sip:701026 at 172.18.81.26:5060 SIP/2.0 > *CAll-ID*: 0029000051a35f9d45ea > *CSEq*: 620309820 INVITE > *FROM*: <sip:701069 at 172.18.80.69>;tag=6815 > To: Sip <sip:701026 at 172.18.80.69>;tag=0029000051a25f9d45ea > *ViA*: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK1868 > Max-Forwards: 70 > Content-Length: 0 This is not true, pjsip does handle mixed case (or "wrong" case). I'm not sure why your test showed different result. > *7. No reply to message with unknown parameter.* > Example: > BYE sip:701026 at 172.18.81.26:5060;*paramUnknown=nonunderstood* SIP/2.0 > Call-ID: 0029000051985f9d45ea > Content-Length: 0 > CSeq: 991774943 INVITE > From: <sip:701069@172.18.80.69>;tag=6265 > Max-Forwards: 70 > To: SipProne26TTCN80 <sip:701026 at 172.18.80.69>;tag=0029000051975f9d45ea > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK3459 I can't find anywhere in RFC 3261 that says UAS should reject request URI with unknown parameters, so in this case pjsip should just accept it. I'm not sure what did it mean by "No reply". > *8.No reply to BYE method if From sip uri contains additional parameters.* > Example: > BYE sip:701026 at 172.18.81.26:5060 SIP/2.0 > Call-ID: 0029000053385f9d45ea > Content-Length: 0 > CSeq: 607358849 INVITE > From: <sip:701069@172.18.80.69;*method=CANCEL*>;tag=502 > Max-Forwards: 70 > To: Sip<sip:701026 at 172.18.80.69;method=CANCEL>;tag=0029000053375f9d45ea > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK9108 > > or > > BYE sip:701026 at 172.18.81.26:5060 SIP/2.0 > Call-ID: 0029000053315f9d45ea > Content-Length: 0 > CSeq: 1149224875 INVITE > From: <sip:701069@172.18.80.69?h1=$>;tag=6979 > Max-Forwards: 70 > To: Sip <sip:701026 at 172.18.80.69?h2=$>;tag=0029000053305f9d45ea > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK816 > > BYE sip:701026 at 172.18.81.26:5060 SIP/2.0 > Call-ID: 0029000053245f9d45ea > Content-Length: 0 > CSeq: 1808471132 INVITE > From: <sip:701069@172.18.80.69;*maddr=192.0.0.1*>;tag=6482 > Max-Forwards: 70 > To: Sip <sip:701026 at 172.18.80.69;*maddr=192.0.0.2*>;tag=0029000053235f9d45ea > Via: SIP/2.0/UDP 172.18.80.69:5060;branch=z9hG4bK8848 Again I'm not sure what kind of reply does it expect. As far as pjsip is concerned, requests will be (or should be) accepted as long as the tags match the dialog, and I can't see why pjsip should reject this request just because it has unknown parameters. So in this case, pjsip should process the request and respond it, as long as the tags and CSeq are okay. What do you think? regards, -benny > If you would like to have any additional information about testing, I > can send it. > > regards, > > Vladimir Hozjan
