The Question is not on implementation. The question is how he can Map both the call legs (much like a sniffer application)
Hth sreeram -----Original Message----- From: B, Nataraju [mailto:[EMAIL PROTECTED] Sent: Thursday, August 10, 2006 3:19 PM To: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks); [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] INVITE message in B2BUA sip servers Regards, Nataraju A B > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] > Sent: Thursday, August 10, 2006 2:29 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; sip- > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] INVITE message in B2BUA sip servers > > > Added to my previous mail, > > > any subsequent INVITE with the inverse combination of "From" and "To", > > > will be the INVITE for the 2nd call-leg. > > You don't need to Inverse the combinations. > Because in second lag also "To" will be the same To address and "From" > will be the same From address only difference is the Host name. > So make sure that the host name is ignored at the sniffer when you are > creating the sequence diagram. > [ABN] it's not just the host name difference while handling any new requests sent within that dialog. As I mentioned in my earlier mail (handling similar to RC in steteful proxies). The requests should be handled like a UAS and find the mapping dialog to send it on the other side. For instance, if you receive a request from original UAS, find the matching dialog (using from-tag_2, to-tag_2, call-id_2) then identify the corresponding dialog towards original UAC (using from-tag_1, to-tag_1, call-id_1) then forward it off... > Hth > sreeram > > > -----Original Message----- > From: Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks) > Sent: Thursday, August 10, 2006 2:25 PM > To: 'Venkatesh Joshi'; [email protected] > Subject: RE: [Sip-implementors] INVITE message in B2BUA sip servers > > Hi Venkatesh, > There is no flaw in this logic to map the sequence at the sniffer and it > works. > > HTH, > Sreeram. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Venkatesh > Joshi > Sent: Thursday, August 10, 2006 1:06 PM > To: [email protected] > Subject: [Sip-implementors] INVITE message in B2BUA sip servers > > Hi, > > In the case of a B2BUA sip server, a call from A to B is treated as 2 > separate legs. > > A <--- INVITE ---> Sip server <--- INVITE ---> B > > There is different information in the INVITE from A to the sip server > and the corresponding INVITE from the sip server to B. ( eg: Call-ID > header, CSeq header etc are different) > > In such a case, is there any way we can identify the INVITEs as being > part of the same call ? ie: is there anything in the INVITE header from > sip server to B that we can use to tie it with the INVITE from A to the > sip server ? > > I am working on a wireless application where a controller sniffs the > INVITE packets from both A and B. I need a way to tie the two INVITES > together. Here is what I have thought of so far: > > For every INVITE: > 1. Extract the "From" number from the FROM header (eg: 4567) > 2. Extract the "To" number from the TO header (eg: 1234) > > Then, any subsequent INVITE with the inverse combination of "From" and > "To", will be the INVITE for the 2nd call-leg. In this way, the 2 > INVITEs for the same call can be tied. > > Is there any flaw in this ? > > Or is there a better way ? > > thanks, > Venkatesh > > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) and > may contain proprietary, confidential or privileged information. If you > are not the intended recipient, you should not disseminate, distribute or > copy this e-mail. Please notify the sender immediately and destroy all > copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
