What you have described is correct. A different call id is as good as a
different client, but in this case as it's the same UAC, the To and Contact
header would be the same. So, the registration info in the registrar would be
updated with the new call-id, etc.
Also, each registration request s
Your query is not very clear Hilario.
If you are looking at SIP-PSTN conversion services .. plenty out there.
Some of them that come to mind right now : gafachi, Teleglobe(VSNL), navigata,
sotel.
other providers at
http://www.voip-info.org/wiki/view/VOIP+Service+Providers
- Ben.
--- On Sun,
o:
> Cc: "SIPImplementors Mailing list"
> Date: Tuesday, October 14, 2008, 1:16 PM
> 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
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
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,
Logically talking, you sending a 200 OK signals your willingness to receive RTP
on the ports you advertised in the 200 OK SDP. So yes, start listening on the
advertised RTP ports when you send the 200 OK and don't wait for the ACK. You
have the liberty of not sending any RTP (in case you have t
al Message ----
From: Benjamin Jacob <[EMAIL PROTECTED]>
To: Iñaki Baz Castillo <[EMAIL PROTECTED]>
Sent: Wednesday, August 20, 2008 9:44:02 PM
Subject: Re: [Sip-implementors] 1xx != provisional response
Both mean the same.
RFC 3261 - Section 7.2
any response with a status code
ce of a Contact
> header in a
> reliable 1xx although it seems to make perfect sense.
> It's not mentioned
> in 3262. Table 2 in 3261 states that it is optional in 1xx
> responses to
> INVITE - if that is qualified somewhere else in 3261 please
> let me know
> where as I c
A PRACK must not be forked (it's a request within the dialog created by the
reliable prov response).
The 1xx reliable provisional response MUST contain a contact for the UAS to
respond to directly.
The Proxy may include Record-route headers if it wishes to stay in the
signalling path. The PRAC
Yep, as it's been covered in the diagram, they seem to have missed out the
final response from TU in the Trying state in the write-up.
In the Trying state, a final response from TU must take it to state 'Completed'.
- Ben.
--- On Sun, 7/13/08, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
>
To rephrase a confused line :
1. If UDP, if incorrect SDP length received(greater or less
than advertised in the Content length) or invalid Content length, respond with
an error.
- Original Message
From: Benjamin Jacob <[EMAIL PROTECTED]>
To: sip-implementors@lists.cs.columbia.
of the SDP could be in the next packet.
b. If Content length is less than the actual packet received, respond with
an error.
c. If invalid Content length, respond with an error.
- Benjamin Jacob.
- Original Message
From: Arun <[EMAIL PROTECTED]>
To: sip-imp
codecs listed in the offer and
answer, on the fly),
3. Use codec locking mentioned in rfc3264.txt (Section 10.2 - One of N codec
selection). e.g. lock the codec to the type received in the first RTP packet
received from the other side.
- Benjamin Jacob.
- Original Message
From
Padmaja,
I think you should read more of the RFCs and do a bit of googling for the
thousands of examples on the web, before you post your questions. The one you
mentioned is very elementary. A simple google for "SIP music on hold" will give
you your answers.
- Benjamin Jacob.
---
I think Padmaja's hinting that the proxy has inserted those 3 Vias the first
time itself, before it could spiral it 'out' and receiving it back.
If the proxy had spiralled it out, there would be other proxies's Vias as well.
Care to clear this Padmaja?
--- On Fri, 6/13/08, Scott Lawrence <[E
e.com:5060;branch=z9hG4bK230f2.1
>
> isn't it??
> bye
>
> On Tue, May 27, 2008 at 4:59 PM, Benjamin Jacob
> <[EMAIL PROTECTED]> wrote:
> >
> > Hmmm.. you are talking of msg F8, I presume.
> >
> > RFC 3261, Section 17.1.1.3 Construction of
17 matches
Mail list logo