Hi Benny! Thank you very much for a fast and detailed reply. From your comments, I can assume that in most error cases that I send, missunderstanding of RFC accoured or some implementaion is missing in my application . In near future I will run test against latest SVN trunk version, and will notify you about results. I also put some comments below. Kind regards, Vladimir >-----Original Message----- From: pjsip-bounces@xxxxxxxxxxxxxxx [mailto:pjsip-bounces at lists.pjsip.org] On Behalf Of Benny Prijono Sent: Tuesday, October 09, 2007 5:33 PM To: pjsip embedded/DSP SIP discussion Subject: Re: [pjsip] Test result >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. Excpected is message 200OK from PJSUA. In that case nothing was send. I will check my appliaction, if there is a problem. > > >> *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. > Once again, my application. > >> *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. :) > True. Let say that this is a feature of PJSIP and not a bug :). > >> *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. > It is logical to handle Content-Length as you described. But if values from UDP and from Content-Length differ, PJSIP could assume that something went wrong in communication between peers. I prefer your solution, because this solution increases robustnes of stack. > >> *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. > Test should be changed, thanks for a tip. > >> *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. I will check the application. > > >> *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. I'll check this in my application once again. > > >> *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. > These BYE message did not produce any reply. 200 OK is expected and PJSIP should procede normaly. According to your statment I have feeling that problem is not in PJSIP, but in my applicaton, so I'll search for a problem there. >What do you think? > >regards, > -benny > >> If you would like to have any additional information about testing, I >> can send it. >> >> regards, >> >> Vladimir Hozjan > > > > > > > > >_______________________________________________ >Visit our blog: http://blog.pjsip.org > >pjsip mailing list >pjsip at lists.pjsip.org >http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
