Hi Dale, It seems that the issue is something else...
While looking at the traces i noticed that there is *wild space* in FROM header between *u...@domain* part of intial invite. And because of this whenever UAS is sending 100 trying with same space then my SBC is unable to understand that provisional resposne to reset the timer and hence its keep sending the invite to termination side on leg 2. INVITE sip:#08864#[email protected] SIP/2.0 Max-Forwards: 69 Session-Expires: 3600;refresher=uac Supported: timer To: <sip:[email protected]:5060> *From: <sip:5073877672 @10.63.0.11>;tag=3485271050-559728* P-Asserted-Identity:<sip:[email protected]<sip%[email protected]> > Call-ID: [email protected] CSeq: 1 INVITE Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, REFER, SUBSCRIBE, PRACK Via: SIP/2.0/UDP 10.63.0.11:5060 ;branch=z9hG4bK841cda8a0ddaacdcf2da96a615e91489 Contact: <sip:5073877672 @10.63.0.11:5060> Expires: 180 Call-Info: <sip:10.63.0.11>;method="NOTIFY;Event=telephone-event;Duration=500" Allow-Events: kpml Allow-Events: presence Content-Type: application/sdp Content-Length: 157 My understanding says it should not have, but i haven't found any supportive document for the same. Thanks, Nitin Kapoor On 11 June 2010 21:46, WORLEY, Dale R (Dale) <[email protected]> wrote: > ________________________________________ > From: [email protected] [ > [email protected]] On Behalf Of Nitin Kapoor > [[email protected]] > > UAC(SIP) -----> Invite/without SDP ------> B2BUA -----Invite/with SDP > default port-----> UAS(SIP) > > Here is what happening at my case that my source UA is sending me invite > without SDP to my SBC and my SBC is forwarding the same to termination UA > with default port as per the design. > > But from Termination side I am getting first 183 w/o SDP and others 2 with > SDP before getting 200 OK w/ SDP in the correspondence of initial offer > INVITE. > > And in those 183 I am getting “100rel” in REQUIRE header field which is not > correct according to me. Because my understanding says that in those > scenario where you are getting initial OFFER w/o SDP, PRACK should be not > be negotiate before getting the 200 OK w/ SDP for the initial invite. Hence > I am facing the media issue. > _______________________________________________ > > Given that your B2BUA is not negotiating the SDP in the same way one each > side, it will probably need complex logic to arrange media successfully. > But that is not the problem here. > > It appears that on the termination side, the UAS is behaving correctly > regarding which responses contain SDP. > > In regard to "Require: 100rel" in responses from the UAS, it is allowed to > do that if the INVITE to the UAS contained "Supportd: 100rel". Although > 100rel is not particularly useful if the 1xx response does not contain SDP, > the UAS is permitted to invoke it in those circumstances. > > SIP is a set of features which each has a defined meaning and which a UA > can combine in many ways. In this case, 100rel and SDP negotiation are > independent features. > > Dale > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
