In the PacketCable 2.0, SIP is being used for the IMS core architecture. They 
have a specs on SIP MTA for residential features ( RSTF spec ). NCS ( MGCP ) is 
being used in PacketCable 1.5. 

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 3:05:24 PM
Subject: Re: [Sip-implementors] Retransmission of BYE


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

Reply via email to