Re: [Sip-implementors] SIP REGISTER without expiration of previousREGISTER

2009-05-20 Thread Benjamin Jacob
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

Re: [Sip-implementors] SIP to PSTN

2008-10-19 Thread Benjamin Jacob
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,

Re: [Sip-implementors] re-transmission timer for UAC transaction (INVITE) failed.

2008-10-14 Thread Benjamin Jacob
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

Re: [Sip-implementors] Implementation of INFO in B2BUA

2008-10-14 Thread Benjamin Jacob
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

Re: [Sip-implementors] re-transmission timer for UAC transaction (INVITE) failed.

2008-10-14 Thread Benjamin Jacob
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

Re: [Sip-implementors] Info Msg for DTMF

2008-10-14 Thread Benjamin Jacob
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,

Re: [Sip-implementors] When to open RTP listen port

2008-09-06 Thread Benjamin Jacob
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

Re: [Sip-implementors] 1xx != provisional response

2008-08-20 Thread Benjamin Jacob
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

Re: [Sip-implementors] Proxy forking PRACK

2008-07-15 Thread Benjamin Jacob
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

Re: [Sip-implementors] Proxy forking PRACK

2008-07-15 Thread Benjamin Jacob
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

Re: [Sip-implementors] Bug in "17.2.2 Non-INVITE Server Transaction" ?

2008-07-13 Thread Benjamin Jacob
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: >

Re: [Sip-implementors] SDP Content length

2008-06-30 Thread Benjamin Jacob
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.

Re: [Sip-implementors] SDP Content length

2008-06-30 Thread Benjamin Jacob
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

Re: [Sip-implementors] REG: query related to sdp

2008-06-19 Thread Benjamin Jacob
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

Re: [Sip-implementors] Reg. Music on hold

2008-06-16 Thread Benjamin Jacob
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. ---

Re: [Sip-implementors] Proxy forwarding invite with multiple via headers

2008-06-13 Thread 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

Re: [Sip-implementors] Session with multiple proxy authentication

2008-05-27 Thread Benjamin Jacob
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