Hi Nitin, > UPDATE cannot be used here because it is the case to update "remote target" > which in turn will change the dialog state. > and UPDATE can only modify session related data not Dialog related. > So Re-Invite shall be used here by A as soon as its CONTACT changes.
Quoting from section 5.1 of RFC 3311: UPDATE is a target refresh request. As specified in RFC 3261 [1], this means that it can update the remote target of a dialog. -- Raj Jain mailto:rj2807 at gmail dot com sip:rjain at iptel dot org On Wed, Apr 9, 2008 at 8:20 AM, Nitin Arora <[EMAIL PROTECTED]> wrote: > one correction to what raj said. > UPDATE cannot be used here because it is the case to update "remote target" > which in turn will change the dialog state. > and UPDATE can only modify session related data not Dialog related. > So Re-Invite shall be used here by A as soon as its CONTACT changes. > > but raj can elaborate more this how RTP destination changed automatically. > > Regards > Nitin Arora > > > > > On Wed, Apr 9, 2008 at 5:01 PM, Raj Jain <[EMAIL PROTECTED]> wrote: > > > This doesn't seem like an Asterisk issue to me. Like Treuz said, the > > client must a RE-INVITE (Asterisk doesn't support incoming UPDATE > > processing currently) to modify the remote target (Contact) for the > > BYE from Asterisk to reach the new address of the client. > > > > As far as how the RTP destination changed automatically, Asterisk is > > probably running in NAT traversal mode where the RTP destination is > > being determined from the source IP address of the incoming RTP > > packets as opposed to what's presented in the SDP signaling. > > > > -- > > Raj Jain > > > > mailto:rj2807 at gmail dot com > > sip:rjain at iptel dot org > > > > > > > > > > > > On Wed, Apr 9, 2008 at 7:05 AM, Andrea <[EMAIL PROTECTED]> wrote: > > > Yu Marilyn-Q12239 wrote: > > > > Look at your RTP stream in the trace. Asterisk is not only a SIP > B2BUA, > > > > it is a RTP B2B too. It doesn't need to let B know A's address change > to > > > > forward RTP. > > > > > > > > > > > [EMAIL PROTECTED] wrote: > > > > From: Andrea <[EMAIL PROTECTED]> > > > > > > > > Yes i traced the whole session. you can get the file here: > > > > http://www.fileden.com/files/2008/3/26/1837579/test1.pcap > > > > Asterisk is 49.8 > > > > Client A is 47.103 -> 49.115 > > > > Client B is 49.116 > > > > The only thing i dont traced is that if B hangup the call, asterisk > > > > forward "BYE" message to 47.103 (the old address of A) > > > > Thanks in advance > > > > > > > > It sounds like Asterisk is sending the BYE incorrectly. > > > > > > > > Dale > > > > > > > @Mey.Yu: yes i agree with that, but Asterisk should know the new > > > location of mobile host so he can sends SIP signaling correctly to new > > > address of mobile host. > > > > > > @Dale: yes it's true, Asterisk should send BYE and all the signaling to > > > new address of mobile host, but mobile host should send new INVITE > > > message to fixed host when he change subnet, so it's true that there is > > > a problem in Asterisk but there is a problem in the softphone clients > > > too, in my opinion. > > > > > > I tried the same scenario with OpenSER that not act as RTP/SIP B2BUA and > > > it happens the same things: when the mobile moves, the clients sends RTP > > > correctly to eachother, but no new INVITE from mobile host in new > > > subnet, and still wrong signaling from OpenSER (when the fixed host > > > hangup the call, BYE is sended to old address of mobile) > > > If u want me to post wireshark trace for OpenSER scenario, just let me > know. > > > Regards, > > > > > > Treuz > > > > > > _______________________________________________ > > > Sip-implementors mailing list > > > [email protected] > > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > > _______________________________________________ > > Sip-implementors mailing list > > [email protected] > > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
