Hi All,
Retransmission timer is timer A and IMO if timer A fails then there is no
need to clear the INVITE transaction. INVITE transaction needs to be maintained
till the transaction timer B (which controls transaction timeouts) expires [in
case no response is received in time]. If timer B fai
hahaa.. yep, that's what Shiv's mail says! maybe he couldn't put it down right.
am sure, he translated the line from his native language and then typed it out
in english. no offence Shiv :-)
As Inaki has said, either you have to clarify your scenario.. or if you are
correct in what you were say
Hi Vivek,
It's perfectly alright for the B2BUA to use this mechanism as well. As it seems
you already know it, for a B2BUA, a call are two different call legs.. so it
can treat individual leg with its own preferences/configuration. Depending on
the methods supported, codec negotiation , etc by
Hi Folks,
I have a doubt regarding implementation of INFO in B2BUA.
INFO is used to transport DTMF digit however other information (wireless
signal strength etc) can also be carried over INFO.
In B2BUA, if INFO (with DTMF) is received on first call leg, I need to block
the INFO and generate t
El Miércoles, 15 de Octubre de 2008, Paul Kyzivat escribió:
> > Yes, you mean the 3rd party registration, is it?
>
> Technically this isn't 3rd party registration, which has nothing to do
> with the value of the contacts.
Oh yes, sure, it's a failure of mine. In fact I already knewn the 3rd
regi
Iñaki Baz Castillo wrote:
> El Miércoles, 15 de Octubre de 2008, Paul Kyzivat escribió:
>> Iñaki Baz Castillo wrote:
>>> El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
I was thinking of something more extreme:
REGISTER sip:example.com
To: sip:[EMAIL P
El Miércoles, 15 de Octubre de 2008, Paul Kyzivat escribió:
> Iñaki Baz Castillo wrote:
> > El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
> >> I was thinking of something more extreme:
> >>
> >> REGISTER sip:example.com
> >> To: sip:[EMAIL PROTECTED]
> >> From: si
Iñaki Baz Castillo wrote:
> El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
>> I was thinking of something more extreme:
>>
>> REGISTER sip:example.com
>> To: sip:[EMAIL PROTECTED]
>> From: sip:[EMAIL PROTECTED]
>> Contact: sip:[EMAIL PROTECTED]
>>
El Martes, 14 de Octubre de 2008, Paul Kyzivat escribió:
> I was thinking of something more extreme:
>
> REGISTER sip:example.com
> To: sip:[EMAIL PROTECTED]
> From: sip:[EMAIL PROTECTED]
> Contact: sip:[EMAIL PROTECTED]
> Contact: sip:[EMAIL PROTECTED]
>
> w
2008/10/14 SHIV SINGH <[EMAIL PROTECTED]>:
> Hi,
> Thanks for replying.
> Your understanding is correct.
> Please see the more clarification inline.
>
> --- On Tue, 14/10/08, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
> From: Iñaki Baz Castillo <[EMAIL PROTECTED]>
> Subject: Re: [Sip-implement
2008/10/14 Benjamin Jacob <[EMAIL PROTECTED]>:
> I think what Shiv is trying to depict is :
> 1. UAC has sent out on INVITE
> 2. UAC doesn't get a response in it's time
> 3. Timer B (as per INVITE transaction) expires and it goes onto the
> Terminated state.
> 4. Now you get the responses (provisi
Iñaki Baz Castillo wrote:
> 2008/10/13 Paul Kyzivat <[EMAIL PROTECTED]>:
>
>> You say you don't consider the connection reuse draft. But you should,
>> because its intent is to clarify behavior that is unclear in 3261.
>
> Well, what I want to know is why all the SIP TCP phones I've tryed
> beh
I think what Shiv is trying to depict is :
1. UAC has sent out on INVITE
2. UAC doesn't get a response in it's time
3. Timer B (as per INVITE transaction) expires and it goes onto the Terminated
state.
4. Now you get the responses (provisional/ final) from the other side.
IMHO, you should drop su
Duration in the INFO body is the DTMF tone's play duration.
- Ben.
--- On Tue, 10/14/08, maverick me <[EMAIL PROTECTED]> wrote:
> From: maverick me <[EMAIL PROTECTED]>
> Subject: Re: [Sip-implementors] Info Msg for DTMF
> To: sip-implementors@lists.cs.columbia.edu
> Date: Tuesday, October 14,
Hi,
I want to implement INFO message for transferring DTMFs.
Can someone please let me know the importance of duration field in body.
How, UA shall act on it.
Thanks in advance...
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
2008/10/14 SHIV SINGH <[EMAIL PROTECTED]>:
> Hi All,
> Here I need some clarification on the following issue.
>
> I have generated an INVITE from UAC side and sent it to UAS but the
> re-transmission timer for this INVITE at UAC got failed.
>
> Now in this case what should be my UAC's behavior for
2008/10/13 Paul Kyzivat <[EMAIL PROTECTED]>:
> You say you don't consider the connection reuse draft. But you should,
> because its intent is to clarify behavior that is unclear in 3261.
Well, what I want to know is why all the SIP TCP phones I've tryed
behind NAT allow receiving requests via the
Hi All,
Here I need some clarification on the following issue.
I have generated an INVITE from UAC side and sent it to UAS but the
re-transmission timer for this INVITE at UAC got failed.
Now in this case what should be my UAC's behavior for further responses like
1xx, 2xx etc.
Should I need t
18 matches
Mail list logo
