Thanks Vivek. But as per cablelabs arch, eMTA make use of MGCP protocol for singaling how come sip?
Regards, Praveen On Fri, Jun 18, 2010 at 12:26 AM, Vivek Singla <[email protected]> wrote: > Hi Praveen, > > Its Embedded Multimedia Terminal Adaptor. Its used as a Cable Modem/MTA in > the Cable architecture to connect to CMTS. If you go to Cablelabs website, > you'll get lot of information about this. > > Vivek. > > > > > > ------------------------------ > *From:* praveena ss <[email protected]> > > *To:* Vivek Singla <[email protected]> > *Cc:* "WORLEY, Dale R (Dale)" <[email protected]>; " > [email protected]" < > [email protected]> > *Sent:* Thu, June 17, 2010 2:49:04 PM > *Subject:* Re: [Sip-implementors] Retransmission of BYE > > Hi Vivek, > what exactly eMTA is? > > Regards, > Praveen > > On Thu, Jun 17, 2010 at 11:42 PM, Vivek Singla <[email protected]>wrote: > >> Thanks everyone for the responses to my query. I really appreciate it. >> >> So the Cseq value would remain the same in the 2nd and the 3rd BYEs here. >> >> And the 3rd BYE will get the 200OK from the P-CSCF since P-CSCF maintains >> the information for that transaction until 64*T1. And after 64*T1 if P-CSCF >> gets the BYE, it'll respond with 481. >> >> Thanks, >> Vivek. >> >> >> >> >> >> >> >> >> ________________________________ >> From: "WORLEY, Dale R (Dale)" <[email protected]> >> To: Vivek Singla <[email protected]>; " >> [email protected]" < >> [email protected]> >> Sent: Thu, June 17, 2010 8:26:35 AM >> Subject: RE: [Sip-implementors] Retransmission of BYE >> >> ________________________________________ >> From: [email protected] [ >> [email protected]] On Behalf Of Vivek Singla >> [[email protected]] >> >> I have a scenario here in the lab : >> >> eMTA P-CSCF >> >> Invite--------------------> >> >> <----------------------------180 >> >> <---------------------------200OK >> >> ACK----------------------------> >> >> BYE------------------------------> >> >> <--------------------------------407 >> >> BYE-----------------------------> >> >> <---------------------------------200OK >> >> BYE---------------------------------> >> >> <------------------------------------200OK >> >> >> >> In this scenario the second BYE ( after 407 ) gets the 200OK but after >> 500ms and therefore sends the third BYE ( retransmission ). >> >> 1) The CSeq in second and third BYEs are same ( CSeq: 3 BYE ). Is this >> correct? >> >> 2) The P-CSCF after its gets the 3rd BYE ( retransmission ), sends the >> 200OK back. Shouldn't it send 4xx saying that no transaction exist? I am >> thinking since P-CSCF has already sent 200OK for 2nd BYE, it has terminated >> the transaction and Dialog on its side. So any retransmissions of BYE from >> UAC should be responded back with 4xx. >> _______________________________________________ >> >> The 3rd BYE has the same CSeq (and branch value) as the 2nd because it is >> a retransmission of the 2nd BYE, that is, a duplicate copy. (Note that the >> network is permitted to deliver more than once a packet that has been sent, >> so the UAS (P-CSCF in this case) must be prepared to receive duplicate >> copies.) When the UAS receives a duplicate of a request that it has already >> responded to, it does not re-process the request, but rather retransmits the >> response that it sent to the first copy of the request. This is all >> detailed in RFC 3261. >> >> Dale >> _______________________________________________ >> 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
