Subject: Re: [Sipping] Comments on draft-zhang-sipping-overlap-00.txt

From: Ramesh <[email-masked]>
Date: Tue, 1 Nov 2005 10:09:25 -0700

Hi all,
There is another issue when Interoping with ISUP and using 183 message. We
can send 183, which is translated to CPG in SS7, only after we get to the
ACM state. SAM is before ACM and So sending INFO after 183 is not possiblity
in case of SAM. We need to only use INVITE to send the additional digits.
This brings about another issue with SAM. If the proxy is the router of the
message How will the proxy know to wait for the a complete set of digits
without looking at the payload? Is there any field in the INVITE that states
that there are additional digits coming in the subsequent invites.
Please let us know if we are wrong in our procedure here.

Thanks
Ramesh & phanidra

On 10/30/05, Gonzalo Camarillo <[email-masked]> wrote:
>
> Hi,
>
> some comments on the following draft:
>
> http://www.ietf.org/internet-drafts/draft-zhang-sipping-overlap-00.txt
>
> First paragraph of the introduction:
>
> "There are two approaches of sending overlap signalling in a SIP
> network described in RFC 3578 [2]: sending the subsequent digits in a
> SIP request (e.g., INFO [3]) within an early dialog, or sending a new
> INVITE which contains all the digits received so far every time a new
> SAM is received. RFC 3578 mainly focuses on the INVITE method and
> doesn`t address the INFO method in detail."
>
> This paragraph in misleading. RFC 3578 states that the INFO approach has
> a number of problems, and thus, it is not recommended.
>
> Regarding the INFO-based solution that was proposed a very long time ago
> and you are proposing again in this draft, has the disadvantage that
> does not work with regular UASs. That is, the receiver of the INVITE
> needs to understand the INFOs that follow it. If you are thinking of an
> environment where all you do is trunking between gateways and where you
> will never figure out that a service had to be applied, and was not,
> when you receive further digits, this approach could work. In a more
> general enviornment, it has serious problems.
>
> Therefore, I would only recommend using the INFO-based approach in
> environments with the characteristics I have mentioned before.
>
> Cheers,
>
> Gonzalo
>
>
> _______________________________________________
> Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

--
cheers
ramesh
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP