2009/7/20 Uwe Kastens kiste...@googlemail.com:
Hello list,
Looks like, that my 1st posting is lost.
It's not lost, just nobody replied it.
I don't if anybody give me a hint. Until today I was very sure the the
P-Asserted-Identity is trusted and the P-Preferred-Identity is
untrusted. So
2009/7/20 JC jc.hu...@tom.com:
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.
In this error
Does any one know the regular expression for SIP URI? I know, from ABNF
you can create regex, but I don't want to scracth my head.
regards
sankar
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
2009/7/20 sankara rao bhogi sankara@sun.com:
Does any one know the regular expression for SIP URI? I know, from ABNF
you can create regex, but I don't want to scracth my head.
Are you looking for a regular expression to match if a string is a
correct SIP URI?
Don't do it as a SIP URI is
Iñaki Baz Castillo wrote:
2009/7/20 sankara rao bhogi sankara@sun.com:
Does any one know the regular expression for SIP URI? I know, from ABNF
you can create regex, but I don't want to scracth my head.
Are you looking for a regular expression to match if a string is a
correct SIP URI?
2009/7/20 Alex Balashov abalas...@evaristesys.com:
You must use a SIP parser instead of a regula expression.
Some people try to condense the requirements of parsing a complex grammar
into a single expression, especially when only validation is required and
not extraction of any tokens.
As I
Iñaki Baz Castillo wrote:
2009/7/20 Alex Balashov abalas...@evaristesys.com:
You must use a SIP parser instead of a regula expression.
Some people try to condense the requirements of parsing a complex grammar
into a single expression, especially when only validation is required and
not
Alex Balashov wrote:
Iñaki Baz Castillo wrote:
2009/7/20 Alex Balashov abalas...@evaristesys.com:
You must use a SIP parser instead of a regula expression.
Some people try to condense the requirements of parsing a complex
grammar
into a single expression, especially when only validation is
2009/7/20 Dushyant Dhalia dushyant.dha...@rancoretech.com:
I need to know what should be the request-uri for re-subscription?
Is it a question? :)
The RequestURI in initial/first SUBSCRIBE is set to the resource to which
the subscriber wants to be subscribed to.
Yes.
In NOTIFY the
Hello list,
Looks like, that my 1st posting is lost.
It's not lost, just nobody replied it.
Ok I did not receive the mail via the list.
A good example for understand the difficult meaning of
P-Preferred-Identity (and probably the only onw) is the usage with
anonymous call, where the
2009/7/20 Uwe Kastens kiste...@googlemail.com:
Looks like, that my 1st posting is lost.
It's not lost, just nobody replied it.
Ok I did not receive the mail via the list.
Gmail doesn't display in Inbox a mail sent by you :)
But the mail did arrive to the list:
Hello
I have a question about how to re-originate a request for an in-dialog
challenge. For example, if a re-INVITE gets challenged, when sending
the new request with credentials, would it be correct to just clone
the old route (from the original request) set or consult the dialog
for a change
Some corrections inline:
2009/7/20 Iñaki Baz Castillo i...@aliax.net:
2009/7/20 Dushyant Dhalia dushyant.dha...@rancoretech.com:
In NOTIFY the notifier sends its
contact. Now my question is - is it okay for the subscriber to send
re-subscribe with RequestURI set to the contact it received in
On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castilloi...@aliax.net wrote:
Of course, the Contact in the NOTIFY from the server are equal.
Not really-- successful SUBSCRIBE requests will receive only one
200-class response; however, due to forking, the subscription may have
been accepted by
2009/7/20 Michael Procter mich...@voip.co.uk:
No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
OK to the initial SUBSCRIBE, that's all.
Of course, the Contact in the NOTIFY from the server are equal.
Not exactly. The contact in the notify will not necessarily be the
2009/7/20 Victor Pascual Avila victor.pascual.av...@gmail.com:
On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castilloi...@aliax.net wrote:
Of course, the Contact in the NOTIFY from the server are equal.
Not really-- successful SUBSCRIBE requests will receive only one
200-class response; however,
2009/7/20 M. Ranganathan mra...@gmail.com:
Hello
I have a question about how to re-originate a request for an in-dialog
challenge. For example, if a re-INVITE gets challenged, when sending
the new request with credentials, would it be correct to just clone
the old route (from the original
On Mon, 2009-07-20 at 10:20 -0400, M. Ranganathan wrote:
Hello
I have a question about how to re-originate a request for an in-dialog
challenge. For example, if a re-INVITE gets challenged, when sending
the new request with credentials, would it be correct to just clone
the old route (from
Ahem:
2009/7/20 Iñaki Baz Castillo i...@aliax.net:
2009/7/20 Michael Procter mich...@voip.co.uk:
No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
OK to the initial SUBSCRIBE, that's all.
Of course, the Contact in the NOTIFY from the server are equal.
Not exactly. The
2009/7/20 Michael Procter mich...@voip.co.uk:
Sorry, but those other NOTIFY will have a different From-tag so they
will discarded with 481 by the subscriber as they don't match the
dialog (From-tag, To-tag and Call-ID) established by the subscriber
and the server whose 200 arrived to the
Race conditions exists (although not likely to occur) where the remote party's
Contact may be updated between sending requests again with update auth headers.
Depending upon loose routing usage, this can impact Route header or
request-uri (see rfc3261 section 16.12.1.2).
The likely hood of
On Mon, 2009-07-20 at 16:37 +0200, Iñaki Baz Castillo wrote:
2009/7/20 Michael Procter mich...@voip.co.uk:
No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
OK to the initial SUBSCRIBE, that's all.
Of course, the Contact in the NOTIFY from the server are equal.
Not
Yeh, the mule draft is the de-facto standard I think.
I believe the called party should send the re-invite because
it is the called fax machine which sends a tone back to say
I'm ready to switch to fax. CED tone, I think.
Regards
Attila
-Original Message-
From:
Hi,
Is there a convention how SIP video terminal should do call hold?
Case-1: [Hold for both audio and video
streams]
c=IN IP4 a.b.c.d
a=sendonly
m=audio
...
m=video
c=IN IP4 p.q.r.t
In SDP body for each media line we have its media attribute values set below
the media line. Each of them have default values if its not mentioned
explicitly in the body..
If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the
media or session
Rajani wrote:
In SDP body for each media line we have its media attribute values set below
the media line. Each of them have default values if its not mentioned
explicitly in the body..
If an offered media stream is
listed as sendrecv (or if there is no direction attribute at the
Brett Tate wrote:
Race conditions exists (although not likely to occur) where the remote
party's Contact may be updated between sending requests again with update
auth headers. Depending upon loose routing usage, this can impact Route
header or request-uri (see rfc3261 section
I can understand how you might dislike the unusual way that forking of
subscribes is handled. It is a special case. It was done that way
because there was a desire to support forking of subscribe, and also a
desire not to institute a transaction state machine for subscribe (akin
to the one for
El Martes, 21 de Julio de 2009, Paul Kyzivat escribió:
I can understand how you might dislike the unusual way that forking of
subscribes is handled. It is a special case.
Yes, I understand.
However, IMHO it's a very bad design and most probably it will never be well
implemented.
As I
29 matches
Mail list logo
