Paul,
Not sure if you read draft-rosenberg-sip-ua-loose-route or not.
I think it talks about the preservation of orig-RURI for service
identification.
FYI
Regards,
-Rockson
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Paul Kyzivat (pkyzivat)
Sent: T
Inaki,
I think that all of what you ask for can probably be achieved through
some combination of HTTP/HTML/flash, IMAP (possibly including extensions
being developed in the lemonade WG) and SIP MWI. Vendors may currently
use proprietary mechanisms for voicemail access from desktop phones but
I
Hi, we already have the MWI protocol to notify the number of read and unread
messages to a subscriber, but AFAIK there is not a integrated protocol to
manage the voicemail remotely (via SIP).
All the solutions I've seen are based on a voice IVR ("press 1 to listen the
message, press 2 to delete
Robert,
Thank you. I was hoping to get that sort of explanation - that the
alternatives had been considered and the one in 3261 explicitly picked.
I knew that my example was contrived, and that it is equally possible to
contrive one for the documented behavior.
And no, I wasn't in Las Vegas. Th
On Sep 8, 2008, at 12:01 PM, Paul Kyzivat wrote:
> Robert,
>
> This wasn't my question, but I have wondered the same thing.
>
> Robert Sparks wrote:
>> Hrmm - I'm not sure I see the confusion yet, but let me describe
>> one concept that drove the text in that section to see if it helps.
>> If
El Lunes, 8 de Septiembre de 2008, Iñaki Baz Castillo escribió:
> Well, I couldn't believe this but after re-read that section it seems
> to be the expected behaviour (behaviour expected just for people
> writting RFC's in other planets, not for any common user/implementor
> in this real world).
Robert,
This wasn't my question, but I have wondered the same thing.
Robert Sparks wrote:
> Hrmm - I'm not sure I see the confusion yet, but let me describe one
> concept that drove the text in that section to see if it helps. If,
> after you read this, you think there's still a lack of clarity
Hrmm - I'm not sure I see the confusion yet, but let me describe one
concept that drove the text in that section to see if it helps. If,
after you read this, you think there's still a lack of clarity, we'll
start walking through the text and see if we can make it better (will
you be at SIPi
2008/9/8, Victor Pascual Ávila <[EMAIL PROTECTED]>:
> Do you mean including the PRIMARY_PATH address in the ";received" even
> though the source address is a different one? This is actually
> possible (See Sockets API Extensions for Stream Control Transmission
> Protocol (SCTP) draft-ietf-tsvwg
On Mon, Sep 8, 2008 at 3:59 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> 2008/9/8, Victor Pascual Ávila <[EMAIL PROTECTED]>:
>> On Mon, Sep 8, 2008 at 3:23 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
>> > Anyway, it seems that SCTP offers some capabilities (IP redundancy in
>> > a si
caio wrote:
> Paul Kyzivat escribió:
>>
>>
>> caio wrote:
>>> I tested a pstn-gw which is confused when INVITE uri is different
>>> from TO header. And I stuck here, with this misunderstanding..
>>
>> That is a seriously broken GW. Tell them to fix it.
>>
>> Paul
>
> nice to known..
> "r-ur
I agree with what others have said. In addition:
This really isn't about the 200 OK. You are to be ready to receive as
soon as you have sent the answer SDP. This *may* be in the 200, but it
can be sooner, in a 180 or 183.
Thanks,
Paul
Rockson Li (zhengyli) wrote:
> Moveover, ev
2008/9/8, Victor Pascual Ávila <[EMAIL PROTECTED]>:
> On Mon, Sep 8, 2008 at 3:23 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> > Anyway, it seems that SCTP offers some capabilities (IP redundancy in
> > a single connection) that SIP can't not advantage of them. Am I wrong?
> > This is: th
dushyant wrote:
>> Hi All,
>
>
>> We are developing IMS core network nodes esp. CSCF. I have a query related
>
>> to implementation of RFC 4028 especially w.r.t. 3GPP TS 24.229 and 3GPP TS
>
>> 32.260 procedures.
>
>
>
> Which of the P/I/S-CSCFs are B2BUAs? All of them?
>
>
>
> --->
On Mon, Sep 8, 2008 at 3:23 PM, Iñaki Baz Castillo <[EMAIL PROTECTED]> wrote:
> Anyway, it seems that SCTP offers some capabilities (IP redundancy in
> a single connection) that SIP can't not advantage of them. Am I wrong?
> This is: the transport layer knows about associations between IP:port
> an
> Question:
> If the SCTP association is open, shall we forward the response to "Address
> 2" even though "Address 1" (PRIMARY PATH) may be recovered?
> If the SCTP association is no longer open, shall we open a new association
> towards "Address 2"?
think so. Maybe a new connection with "
Hi,
RFC4168: Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the addresses,
but if it becomes unreachable, data sent to one can migrate to a different
address.
Please, consider the following scenario:
Proxy A (Addres
Paul Kyzivat escribió:
>
>
> caio wrote:
>> I tested a pstn-gw which is confused when INVITE uri is different from
>> TO header. And I stuck here, with this misunderstanding..
>
> That is a seriously broken GW. Tell them to fix it.
>
> Paul
nice to known..
"r-uri" and "to" fields seem to
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz
Castillo
Sent: Monday, September 08, 2008 5:20 PM
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Question on proxy routing
2008/9/8, Rockson Li (zhengyli) <[EMAIL PRO
2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Inaki,
>
> Actually, I think this the essence of SIP proxy, have you ever imagined why
> mid-dialog req get passed through proxy?
> IMO, after proxy populates the target(s) (usually, proxy would not
> responsible for the uri,since it's remo
Inaki,
Actually, I think this the essence of SIP proxy, have you ever imagined why
mid-dialog req get passed through proxy?
IMO, after proxy populates the target(s) (usually, proxy would not responsible
for the uri,since it's remote peer's contact uri,
the target is just the same as req-uri), so
2008/9/8, Rockson Li (zhengyli) <[EMAIL PROTECTED]>:
> Franz,
>
> IMO, the proxy need first replace the req-uri with target, and forward
> the request to next hop based top route.
>
> The reason is as per RFC3261
>
> 1)Proxy first Determining Request Targets based on req-uri
> 2)then forward t
22 matches
Mail list logo
