On Mon, 2010-03-08 at 12:49 +0530, hanifa.mohammed wrote:
> 5.2. Generating a REGISTER Response
>When generating the 200 (OK) response to the REGISTER request, the
>procedures of step 8 of Section 10.3 of RFC 3261 [1] are followed.
>Furthermore, for each Contact header field value pla
On Fri, 2010-03-05 at 11:48 +0530, Amarnath Kanchivanam wrote:
> Can anyone help me in understanding the difference BTW session and dialog?
The session is the "media", usually streams of RTP packets. A session
is described by SDP.
The dialog is relationship that is created/destroyed by the SIP
m
On Tue, 2010-03-02 at 16:49 +0530, Sunita Bhagwat wrote:
> I'd like to know if a SIP gateway receiving a 181 (Call is being
> forwarded) or a 182 (call Queued) from SIP peer should play local
> ringback towards the originating endpoint (say PSTN/ISDN). RFC 3960
> mentions early media and ring-back
On Mon, 2010-03-01 at 11:01 +0530, Bajaj, Gagandeep wrote:
> Hi Dale
>
> Thanks for the response.
>
> Referring to RFC 5359, my question is regarding F15 containing sipfrag
> body with "SIP/2.0 488 Not acceptable".
There is no such F15 in RFC 5359 -- the only F15 in section 2.4 contains
a sipf
On Mon, 2010-03-01 at 02:33 -0800, Arunachala wrote:
>One of our UA's creates the FROM URI in its outbound INVITE as follows:
> 1. If an outbound proxy is configured, puts the proxy's FQDN/ip in the
> hostname of From URI.
> 2. If no outbound proxy is configured, puts its OWN ip/FQDN in
> hostn
On Wed, 2010-02-24 at 21:16 +, Aaron Clauson wrote:
> Since that would take extra work on the server and the client I'll be a
> heretic and stick to my 184 info response approach for the time being. It's
> not much of a contravention of the standard. A UAS can send back as many
> info responses
On Fri, 2010-02-26 at 12:26 +0100, Iñaki Baz Castillo wrote:
> Hi, I've some interoperability problems with a PBX sending DTMF events as
> follows:
>
> RFC 2833 RTP Event
> Event ID: DTMF Eight 8 (8)
> 0... = End of Event: False
> .0.. = Reserved: False
> ..00 = V
(I assume you are referring to RFC 5359 section 2.4.)
On Fri, 2010-02-26 at 14:17 +0530, Bajaj, Gagandeep wrote:
> Bob sends NOTIFY "terminated" (15th message) to inform Alice that he has
> successfully connected with Carol.
Beware that it in F15, it is not "Subscription-State: terminated" that
On Mon, 2010-02-22 at 21:19 +, Aaron Clauson wrote:
> The problem I have is that the client does not actually know all the
> redirects at the point the first one is sent. The client has a human user
> pressing buttons to initiate the redirects and there could be gaps of
> 1,2,5,10 etc. seconds
On Thu, 2010-02-18 at 02:50 +, Aaron Clauson wrote:
> I have a scenario where I want a SIP client to be able to generate multiple
> redirect responses. The redirect responses will be generated based on user
> actions and will have a variable delay between them.
>
> As far as I can see there is
On Mon, 2010-02-15 at 11:16 -0800, Brett Tate wrote:
> RFC 3262 allows the UAS to send a final response (such as 200 OK) to
> INVITE within some situations while there are still outstanding
> unacknowledged reliable provisional response. Is it acceptable to
> send 481 response for unacknowledged r
On Fri, 2010-02-12 at 07:33 -0500, Nitin Kapoor wrote:
> Could anyone please help me out on this scenario. Why it’s not sending
> the RTCP attribute to my UAC? Is there anything related to standard.
Have you checked the configuration of the SBC or asked the SBC's
manufacturer? Within SIP, there i
On Thu, 2010-02-11 at 10:39 +0530, Bala Murugan wrote:
> Thanks for your response , but in the call flow I have mentioned ,
> INVITE transaction is completed ,can you look at below flow the 200OK
> to INVITE has been already sent from UAS to UAC .My question can a UAC
> send RE-INVITE if the UPDATE
On Tue, 2010-02-09 at 22:16 +0100, Olle E. Johansson wrote:
> Oh. That's evil. I new I could count on you to come up with something
> even more stressful than what I could imagine in my strange SIP mind.
> We need to remember that for next SIPit. ;-)
As a general rule, any observation "XYZ can hap
On Wed, 2010-02-10 at 18:14 +0530, Bala Murugan wrote:
> Can a UAC send RE-INVITE , if a response is pending from UAS for
> UPDATE refresh Request in early dialog .
The UAC cannot send a re-INVITE in an early dialog, because its first
INVITE has not completed. See RFC 3261 section 14:
Note th
On Wed, 2010-02-10 at 20:11 +0900, Couret Tabt wrote:
> There is a description below about 407 in RFC3261:
>
> 21.4.8 407 Proxy Authentication Required
>
>This code is similar to 401 (Unauthorized), but indicates that the
>client MUST first authenticate itself with the proxy. SIP access
On Tue, 2010-02-09 at 09:24 +0100, Olle E. Johansson wrote:
> Isn't there an important difference to be noted here. In one call
> setup, you can have multiple 407 challenges, but only one 401.
> If you're using an outbound proxy, that proxy can challenge you, as
> well as the home proxy and the UA
On Mon, 2010-02-08 at 21:18 +0530, zabi wrote:
> If the REQUEST_URI/ TO / FROM /CONTACT has escaped sequence, does the
> response have to have the same escaped sequence or it may have its
> parsed values.
>
> For e.g if the username in sip request had b%...@example.com.
>
> can the response hav
On Mon, 2010-02-08 at 18:32 +0900, Couret Tabt wrote:
> I have a question about '407 Proxy Authenticate Response'
> in RFC3261 below:
>
> May a UA(ex.Bob as a receiver) send '407 Proxy Authenticdate' Response
> as same as a proxy send.
In theory, a UAS must use 401 and a proxy must use 407. But
On Sat, 2010-02-06 at 21:43 +0530, Rohit Aggarwal wrote:
> RFC 3261 also says that although Require is an optional header, it must not
> be ignored if present.
> In that case, it may be better option to cancel the request.
IMO canceling the request is the one thing the UAC should not do. If
the
On Fri, 2010-02-05 at 16:37 -0500, preynold wrote:
> I have a question regarding appropriate behavior for a UAC when it receives
> a provisional response containing a Require header with an unrecognized tag.
> What should the UAC do? Ignore the provisional response? Process the
> provisional respon
On Fri, 2010-01-29 at 19:30 +0900, OKUMURA Shinji wrote:
> Consider the following scenario.
>
> | INVITE(CSeq:1)|
> |--->|
> ||
> | 18x |
> |<---|
> |
On Wed, 2010-01-20 at 17:02 +0530, sunil.bha...@wipro.com wrote:
> I have a doubt regarding Reason Header in BYE request.
>
> We can have the different Reason Header in BYE request depending on the
> call state. Some of the examples are given below:
>
> Reason: SIP ;cause=600 ;text="Busy Everywhe
On Wed, 2010-01-20 at 14:22 +0800, LIU Liping wrote:
> When TCP is used as transport lay for SIP messages. Maybe the SIP
> Stack can read some data from socket which includes more than one sip
> message and maybe the SIP stack can read only a part of a sip message.
> So, now Is it the stack's duty
On Tue, 2009-12-15 at 09:43 -0500, Adam Frankel wrote:
> > Any ideas if this is actually required per RFC [3326] Standard or if
> > the "text=" portion of the reason header is only optional?
The BNF in RFC 3326 clearly shows the 'text' parameter as optional, and
I don't see anything in the text of
On Mon, 2009-12-14 at 17:43 +0530, Dushyant Dhalia wrote:
> 1. Does the proxy server have to start a timer for receipt of NOTIFY?
No, because the proxy need not be stateful (beyond a single
request/response transaction). The UAs are responsible for keeping
track of the subscription state.
Dale
On Fri, 2009-12-11 at 09:47 +0100, javier.ferreirogar...@telefonica.es
wrote:
> A doubt about UA implementation when a 302 is received as response to an
> INVTE.
> How shall de new INVITE be built? Shall the UA keep the same Call-Id, the
> same tags, increment CSeq, change the brach? Is this beh
On Tue, 2009-12-08 at 23:42 +, Brez Borland wrote:
> Dale has a point. I was impressed watching talk dedicated to ipv6
> where major minds behind ipv6 development seemed to be straight
> ignorant, or least interested, in the notion of private network
> implementations such as NAT. their positio
On Tue, 2009-12-08 at 00:56 +0100, Iñaki Baz Castillo wrote:
> I just mean SIP/TEL URI's for two purposes:
>
> 1) For user/device SIP identity (I've never seen a SIP AoR containing
> parameters).
>
> 2) The XUI field of XCAP URI (XUI is the AoR of the user whose document we
> desire).
>
> So I
On Mon, 2009-12-07 at 17:30 -0500, pvall...@csc.com wrote:
> When will that happen to SBCs..:)
Actually, SIP works quite well with SBCs, as long as the SBC does not
attempt to restrict what features of SIP are used. Unfortunately, many
service providers configure their SBCs not only to perform s
On Mon, 2009-12-07 at 21:11 +0100, Iñaki Baz Castillo wrote:
> El Lunes, 7 de Diciembre de 2009, Dale Worley escribió:
> > On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote:
> > > I still wake up every day asking myself how SIP protocol was born
> > &g
On Mon, 2009-12-07 at 14:11 +0530, Gaurav Nangla wrote:
> Is there an approppriate algorithm like the 'Session-ID generation algorithm'
> proposed in http://tools.ietf.org/html/draft-kaplan-sip-session-id-02, for
> the Call-ID header and icid-value (P-Charging-Vector) param.
>
> If another develop
On Wed, 2009-12-02 at 13:14 +0530, hanifa.mohammed wrote:
> "However, a UA MUST be prepared for the public GRUU to change from a
> previous one, since the
> persistence property is not guaranteed with complete certainty."
>
> So, even for a refresh-REGISTER, the public GRUU may be different.
On Tue, 2009-12-01 at 13:44 +0100, Iñaki Baz Castillo wrote:
> Hi, if there any *real* case in any SIP core (i.e: IMS) in which a user could
> have a URI with parameters?
IMS is hardly "core" SIP usage.
If your question is "Should my system be able to handle SIP URIs with
parameters?", the answe
On Mon, 2009-11-30 at 12:32 -0500, Paul Kyzivat wrote:
> > I have a doubt on this. Should this behavior be of stateful proxy or can
> > stateless proxy also do this? In my understanding, a stateless proxy should
> > not do anything on its own and it should actually pass it to UAC. Is this
> > under
On Fri, 2009-11-20 at 14:38 +0530, Siddhartha Singh wrote:
> I have running test scenario in which there is sip dialogue established &
> them
> short message (data) is send in V23 format in RTP stream.
>
> I have to ckeck for conformance of transmission mode of V23 in RTP packet,
> We have fi
On Thu, 2009-11-19 at 14:47 +0800, Zhaoning Jiang wrote:
> SIP gurus, Please help identify this issue.
>
> Do Standard allow send Port=0 with FQDN in Req-URI?
>
> like
> t...@icscf-stdn.xxx.com:0 ?
>
> I went through RFC3261 and did not find answers.
The difficulty is that port 0 is a perfectly
On Thu, 2009-11-19 at 11:49 +0530, hanifa.mohammed wrote:
> Hi all,
>
> It is very common that a single UA stack, in a device, shall be used by
> many users. In that case,
> shall all users use a common instance-id? Will it give any trouble, in real
> time?
>
> Pl clarify whether instance-i
On Wed, 2009-11-18 at 00:15 +0100, Iñaki Baz Castillo wrote:
> I still wake up every day asking myself how SIP protocol was born assuming
> there is no NAT... :(
How long have you been involved with the IETF? A lot of IETF people
hate NATs like the Pope hates Satan.
Dale
On Mon, 2009-11-16 at 19:35 +0530, hanifa.mohammed wrote:
> When the 401 resp of Register has "Supported:outbound", can UAC
> assume that the server has outbound support. Or, should it wait for 200 Ok
> resp?
>
> Below is an excerpt from RFC 5626.
>The UAC examines successful registration res
On Sat, 2009-11-14 at 19:57 +0530, Shamik Saha wrote:
> If there is a contact address that contains an octothorpe # as a prefix,is
> that a valid contact,the contact is of the form
>
>
> contact :
Check the BNF in section 25.1 of RFC 3261. In this case, the user-part
is specified by the produc
On Fri, 2009-11-13 at 10:56 +0800, Tsunghao Lee wrote:
> I have a question about maxinum size of MIME body in SIP MESSAGE.
There does not seem to be a defined maximum size. But there is a
response code (513) for reporting that a request's size is larger than
the UAS can process.
Dale
_
On Wed, 2009-11-11 at 18:35 +0530, Ayyanar PK wrote:
> I don't want to receive 407, instead I want to send Authorization
> credentials in the initial itself so that the proxy allows the call.
> Please read RFC3261 section referred below. In that case what are the
> parameters to be sent in ProxyAut
On Fri, 2009-10-23 at 11:15 +0100, Attila Sipos wrote:
> interesting. "Spotter's badge" for you!
Indeed!
> I suspect that SIP changed it because it is best to have
> to most important headers at the top - less time to parse down?
I think that was the idea. Consider this sentence from section 7
On Mon, 2009-10-19 at 22:54 +0200, Iñaki Baz Castillo wrote:
> Does it means that a request with From "sip:al...@domain.org" and credentials
> with "username=bob, realm=domain.org" would be accepted by sipXecs and routed
> to the destination?
> This means that bob is spoofing the call originator.
On Mon, 2009-10-19 at 16:51 -0400, Dale Worley wrote:
> I've written up an internet-draft [...]
It can be obtained at
http://www.ietf.org/id/draft-worley-instrument-identification-00.txt
Dale
___
Sip-implementors mailing list
Sip-impl
ubmission Tool wrote:
> A new version of I-D, draft-worley-instrument-identification-00.txt has been
> successfuly submitted by Dale Worley and posted to the IETF repository.
>
> Filename: draft-worley-instrument-identification
> Revision: 00
> Title:
On Thu, 2009-10-15 at 13:54 +0530, Bitan Kundu wrote:
> Should a SIP call get established if the username (Authorization OR
> Proxy-Authorization header) and the userinfo portion of the 'From' uri is
> different? Please point to the RFC section if anywhere it is mentioned.
There is no single answe
If you have experience in SIP performance metrics, you might want to
join the discussion of "draft-ietf-pmol-sip-perf-metrics" on the IETF
working group mailing list . That internet-draft is a
proposed standard for SIP performance metrics.
Dale
___
Si
On Fri, 2009-10-02 at 15:20 +0200, Iñaki Baz Castillo wrote:
> El Viernes, 2 de Octubre de 2009, Laurent Etiemble escribió:
> > Hello,
> >
> > If you want to test protocol switching, try the Mercuro IMS Client
> > (http://www.mercuro.net/). It supports the ability to switch from UDP
> > to TCP whe
On Thu, 2009-10-01 at 10:37 +0200, DE CLERCQ Johan wrote:
> As we all know, in ISDN you can detect when you go to a voicemailbox of
> a cellular line by looking for the PROGRES message as defined in Q.931.
There is no good way to do this in SIP. However, an answering automaton
"should" identify i
On Wed, 2009-08-26 at 17:10 -0400, Szilagyi, Mike wrote:
> I’ve not been able to find definitive text regarding this issue so I’m
> hoping someone can provide clarification. If a request (INFO or
> UPDATE) is sent on a dialog in the early state, how are the CSeq
> numbers managed by the UAS. Here
On Tue, 2009-08-04 at 13:13 +0200, be...@telekom.de wrote:
> What should a notifier send in its initial NOTIFY if it doesn't have
> valid state information?
As you've described below, the definition of the event package is
supposed to contain that information.
> Do end devices handle NOTIFYs with
On Tue, 2009-09-29 at 22:50 +0200, Mihaly Zachar wrote:
> Lets say I get the first INVITE from 10.1.1.1:53000.
> When I send the ReINVITE to the A leg it sends back the "100 Trying" and
> then the "200 OK" from 10.1.1.1:5060.
>
> Is this correct ?
> Can the UAC change port within a SIP transaction
On Tue, 2009-09-29 at 15:32 +, Scott Lawrence wrote:
> On Mon, 2009-09-28 at 16:05 +0530, Thomas george wrote:
> > Hi,
> >
> > In case the Authentication takes more time for a SUBSCRIBE request,
> > Can I first send 202 response to the SUBSCRIBE request and later send 401?
>
> No - proxies wi
I see in RFC 3261 saction 17.1.1.3, titled "Construction of the ACK
Request". Have you carefully checked your ACK against its
specifications?
In regard to the example you provide, the 408 response has no to-tag,
which is quite strange for any modern SIP device.
Dale
___
On Wed, 2009-09-23 at 06:19 -0700, Bharat S wrote:
> In case of a call transfer, when a REFER request is received at
> Transferee (from Transferor), what is the method carried in the Cseq
> Header for the INVITE request originated towards Transfer Target?
> As per RFC 5589 in case of basic call tra
On Mon, 2009-08-24 at 08:26 -0700, Amy Hwang wrote:
> Let's say SDP is offered with the following media line:
>
> m=audio 12345 RTP/AVP 97
> a=rtpmap:97 PCMU/8000
>
> That is, a dynamic payload type of 97 is being used to represent
> PCMU/8000, which is also mapped to the static payload type of 0
On Tue, 2009-09-08 at 23:24 +0200, Thomas Gelf wrote:
> The problem we were talking about are clients filling the registrars
> location database with multiple (usually in the range of 3-30) different
> records. Same UAC, same Call-ID, same username, same (official) IP but
> changing port in their C
On Sun, 2009-08-30 at 12:20 +0530, vijay wrote:
> Hi,
> If we get different contact in 200 response for Register request, Is it
> successful registration?
> If yes, Can we consider the expires(for reg refresh) value present
> in the Contact?
> If no, Please suggest, what should we d
On Sat, 2009-08-15 at 23:35 +0800, T Satyanarayana-A12694 wrote:
> Additional round trips should be made optional (only for implementations
> having concurrent codecs limitation).
>
> Additionally, why can't the spec be modified (or place in a BCP):
> 1. to allow only a sub-set (of what is presen
On Fri, 2009-08-14 at 14:41 +0800, Rockson Li (zhengyli) wrote:
> I think answerer can add additional codec G729 here per sec 6.1 of
> rfc3264
>
>
>The stream MAY indicate additional media formats, not listed in the
>corresponding stream in the offer, that the answerer is willing to
>
On Mon, 2009-08-10 at 17:52 +0530, Aryan wrote:
> Actually i am having an issue when 183 is not unreliable , but 180 is
> reliable. But i have read somewhere that 183 is more preferred over 180,
> right?
No... In general, the answerer may send the answer in some or all of
the provisional response
On Tue, 2009-08-04 at 10:53 +0530, Ujjwal SIngh wrote:
> What does
>
> "SIP/2.0 487 LR2 - User not registered on this client means."
>
> I am getting this error from a server when I send an INVITE to the server.
Some SIP systems will not accept INVITEs from phones that are not
registered with th
On Mon, 2009-08-03 at 14:03 +0200, Schwarz Albrecht wrote:
> Right, the draft is very initial, the crucial part is just the SDP
> example only.
> As soon as we got agreement that the SDP syntax is correct and inline
> with SDPCapNeg and SDPMediaNeg, we'll polish the text and update
> scope, abstrac
On Fri, 2009-07-31 at 15:23 +0200, Schwarz Albrecht wrote:
> http://www.ietf.org/internet-drafts/draft-schwarz-mmusic-sdp-offer-answer-examples-00.txt
>
> Dear SDP Offer/Answer experts!
>
> Our draft provides an example in § 4.4.1.3, using the new SDP syntax
> according revised SDP O/A:
> "SDP Ca
On Thu, 2009-07-30 at 16:01 +0530, hanifa.mohammed wrote:
> On receiving 407 for the intiail INvITE request, should the Route-set
> be updated in the caller side?
No: Because the request failed, it has no effect on the dialog state.
In addition, since the initial request failed, it does not creat
On Tue, 2009-07-28 at 19:52 +0530, rishabh wrote:
> Is it important to change the version number in every communication we have.
>
> if not what will be the result.
If the contents of the NOTIFY do not change, then the version need not
be changed. But if the contents of the NOTIFY are different
If the far-end UA has set its Contact URI to have "+sip.rendering=no", I
think that can be safely taken as "the far-end has put us on hold".
Other than that, if all the media streams are on "sendonly" or
"inactive", you could consider the call to be on hold.
Dale
On Tue, 2009-07-21 at 22:50 +0200, Iñaki Baz Castillo wrote:
> > And it is implemented
> > correctly in the sipXecs proxy system (and most likely all other
> > high-quality SIP implementations).
>
> I don't understand what you mean, a proxy has nothing to do here:
sipXecs also includes a consider
On Mon, 2009-07-20 at 11:59 +0800, JC wrote:
> My scenario is as follows, one SIP client sends one fresh SUBSCRIBE to
> SIP server via TCP, and SIP server sends 200OK back immediately.
> Unfortunately, SIP client does incorrect thing to retransmit SUBSCRIBE
> once before it gets final response.
On Tue, 2009-07-21 at 01:54 +0200, Iñaki Baz Castillo wrote:
> As I explained in my other mail, parallel forking in subscription is really a
> corner case. But the logic and code to implement it in the client is really
> complex. I expect that a vendor cannot spend so much time to implement such
On Fri, 2009-07-17 at 18:32 +0100, Ron Bowater wrote:
> We have a problem with SIP Blind Transfer using REFER where we get the
> Notify (100) but then we don't receive the Notify (200) within the time that
> the application is prepared to wait for. What we do at the moment is to send
> the INVITE t
On Thu, 2009-07-16 at 17:53 -0400, Lakshminarayana Jayaprakash wrote:
> Is there a convention how SIP video terminal should do call hold?
Remember that there is no specified concept of "hold".
Presumably, you put a multi-media call on hold by setting all the
streams to "sendonly".
Dale
On Thu, 2009-07-09 at 13:33 +0200, Michael Hirschbichler wrote:
> UAC Proxy
> REGISTER>
> <401 Unauthorized (w challenge)--
> ---REGISTER (w correct Credentials)->
> <401 Unauthorized (w challenge)--
>
> (The credentials are correct
On Thu, 2009-07-09 at 08:07 -0400, Uttam Sarkar wrote:
> Please see the definition of Refer-To header.
>
> 2.1 The Refer-To Header Field
>
>Refer-To is a request header field (request-header) as defined by
>[1]. It only appears in a REFER request. It provides a URL to
>reference.
>
On Wed, 2009-07-08 at 08:32 -0400, Dan Mongrain wrote:
> RFC 3261 basically mentions that UAC can fail a transaction in the case
> of no response after 64*T1 (retransmitting every 2*T1). With the
> default T1 being 500ms, 32 seconds is a long time to wait especially
> when there are multiple p
A major difficulty is that the only IP/port/transport that you *know*
the sender is listening on is the one specified in the Via. Many if not
most SIP elements will properly process a SIP message no matter what
port it is received on, but there is no guarantee that the sending
element is listening
On Thu, 2009-06-25 at 15:34 +0530, Krishna Rao Gurram wrote:
> Does this mean port number must not be present in the From and To
> headers?
> The grammar for From and To headers permits the presence of port
> number in the From / To URIs.
The port number should be put in a From/To URI if that is n
On Wed, 2009-06-17 at 17:10 +0400, Kashin Mihail wrote:
> Hi, everybody!
>
> Is it legitimate for UAS to request reliable provisional response
> option after receiving INVITE without Required or Supported headers.
>
> In my case the flow is like this
>
>
>
> Inv (no 100Rel*)->
>
> <-100 Tryi
On Tue, 2009-06-23 at 16:24 +0200, Iñaki Baz Castillo wrote:
> 2009/6/23 Sudhir Kumar Reddy :
> > thanks folks for detailed info. can we consider following
> > P-Asserted-identity Header
> >
> > P-Asserted-Identity: "Cullen Jennings" ; urip=1234
> >
> > or should we consider following
> >
> > P-A
On Tue, 2009-06-23 at 11:55 +0530, Dushyant Dhalia wrote:
> I have a basic query regarding offer-answer model.
> Why can't/don't UAC & UAS use the same session-id in "o=" line of the
> SDP? I agree that RFC 4566 define session-id as
> is a numeric string such that the tuple of ,
> , , , and for
On Sun, 2009-06-21 at 01:45 +0800, ChunSean wrote:
> Hi all, I am planning on developing a SIP application on knopflerfish osgi
> framework. I face some difficulties when developing the program. This
> program is planned to be able to
Writing a SIP application is a great deal of work. I would sug
On Fri, 2009-06-12 at 22:38 +0600, Manoj Priyankara [TG] wrote:
> In this case UAC B should have a mechanism to release the call leg by
> observing RTP (or some other protocol than SIP) and then of course UAS
> can release the session.
>
> This seems to be a possible way to handle the situation if
On Thu, 2009-06-11 at 15:11 +0600, Manoj Priyankara [TG] wrote:
> Let us imagine that UAC's A and B are in a call and due to a network
> connectivity problem, user A disconnects without sending any message to
> the UAS.
> Then the UAS still thinks that UAC A is alive. Of course if we have SIP
> OPT
On Wed, 2009-06-10 at 21:22 +0200, Iñaki Baz Castillo wrote:
> El Miércoles, 10 de Junio de 2009, Dale Worley escribió:
> > And a UAC might want to display the reason phrase, so you could use
>
> Do you mean that the UAC could display the reason phrase in *English*? IMHO a
> s
On Wed, 2009-06-10 at 21:13 +0200, Iñaki Baz Castillo wrote:
> Yes, it could reply
> a 182 with SDP but, how many today's devices would render the SDP in a 182
> response?
They all should. That's a central tenet of SIP design -- there is a
default behavior for each class of responses that a dev
On Wed, 2009-06-10 at 15:01 -0400, Simon Perreault wrote:
> Iñaki Baz Castillo wrote, on 2009-06-10 14:49:
> > Hi, calling today to a cell phone I've seen in my mobile screen:
> > "Call waiting in the other side"
> >
> > Does something similar exist for SIP?
>
> Isn't this exactly what code 182
On Sat, 2009-06-06 at 12:31 +0200, Iñaki Baz Castillo wrote:
> Hi Dale, please don't take me wrong but that sounds too much exotic for me
> and
> I don't expect a SIP device being so clever in the next 25 years XD
I wouldn't be surprised if the peer-to-peer SIP people use such a
scheme. After a
On Tue, 2009-06-02 at 18:14 +0200, Iñaki Baz Castillo wrote:
> Anyhow, it seems that before securing the media transmission, it makes
> sense to also secure the signalling. Since TLS secures the signalling
> it allows the secure tranmission of master key for SRTP. This is, with
> TLS you get all th
On Tue, 2009-06-02 at 03:39 -0700, Radha krishna wrote:
> What should be the SDP in the following scenario.
>
> 1) UA1: Send INVITE with 3 codec's. A, B and C.
> 2) UA2: Received 200 with Codec A.
> 3) UA1: Session timer expired.
> 4) UA1:
On Sun, 2009-05-31 at 15:03 +0200, Rodriguez Merchan, Pedro Julian
wrote:
> Could you help me about making Gateway ISDN supplementary services
> betwen SIP and ISDN (Q931/QSIG)?
Some work has been done on this, but not a lot. E.g., the IETF Bliss
working group has done work on interoperation of "
On Mon, 2009-06-01 at 11:58 +0530, hanifa.mohammed wrote:
> Pl find the snippet from RFC3265:
>
> "If, for some reason, the event package designated in the "Event"
> header of the NOTIFY request is not supported, the subscriber will
> respond with a "489 Bad Event" response."
>
> It means tha
On Tue, 2009-05-26 at 09:21 +0300, Brocha Strous wrote:
> Is the following line valid:
>
> a=rtpmap:101 telephone-event/000
>
> What is the meaning of a 0 clock rate? And isn't it supposed to be a
> number? I tried to find somewhere a BNF specification for RTPMAP
> attribute lines but only found
I believe that we have discovered that the RFC 3261 grammar allows
whitespace at the end of (almost) no headers. But people expect that
parsers will accept (linear) whitespace at the end of all headers.
Dale
___
Sip-implementors mailing list
Sip-imple
On Wed, 2009-05-13 at 15:30 +0530, Ashwath Kumar wrote:
> So if proxy is sending 404 not found is it valid behavior of the proxy ?
> or should we expect 5xx 'loop detected' ?
482 is used for "Loop Detected" (this request has passed through this
proxy before) and "Merged Request" (a copy of this r
On Tue, 2009-05-12 at 14:25 +0530, Kapil Saxena wrote:
> I have a MGW that has SIP interface towards UE and ISUP towards MSC.
>
> For a SIP->ISUP call:
>
> 1. MGW receives SIP INVITE from UE and sends IAM to MSC-A.
> 2. MGW receives backward ACM message with "called party status =
> free" fro
On Tue, 2009-05-12 at 08:47 +0200, Damir Reic wrote:
> If UAS receives BYE on early dialog and answers it with 200OK, does it have
> to respond to initial invite with 487 (same as CANCEL was received)?
In RFC 3261 section 15.1.2, it says:
The UAS MUST still respond to any pending requests rece
On Mon, 2009-05-11 at 23:06 +0200, Iñaki Baz Castillo wrote:
> > In practice, the solution is for the user agent to perform the transfer
> > in the background by doing nothing until the new call leg is answered,
> > and then sending the REFER that completes the transfer. (This has been
> > underst
On Mon, 2009-05-11 at 18:32 +0200, Francisco José Méndez Cirera wrote:
> A question about the CALL-ID.
>
> 1. UAC sends an INVITE request to Redirect Server with CALL-ID: abc.
> 2. Redirect server sends response "300 Multiples Choices".
> 3. UAC makes a pararell search sending three IN
1 - 100 of 449 matches
Mail list logo
