Hi Vladimir, could you please tell me which conformance test tool you've used? Best Regards, Juri Am Mittwoch, den 10.10.2007, 10:53 +0200 schrieb Hozjan Vladimir: > 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 > > _______________________________________________ > 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 >
