Subject: Re: [Sipping] sipping-siptrunk-00

From: Hendrik Scholz <[email-masked]>
Date: Tue, 11 Mar 2008 20:54:51 +0100

Hi!

Peter Musgrave wrote:
> I like the use of the Route header in section 3 to separate the trunk 
> identity from the called party. Very good idea!

I second that idea.

> Also, the draft mentions PSTN trucks should do mutual TLS and calling 
> party checks. While I agree with this – in practice I have not seen this 
> commonly deployed.

The trunk type definitions in section 2.1 are all based on TCP and/or 
TLS but still section 2.4 mentions the use of UDP.

IPsec tunnels appear to play a role in interconnection scenarios. Both
PSTN interconnection trunks as well as filtering trunks in the real 
world will receive plain UDP signalling which was terminated on
an IPsec gateway right in front of the trunk.
This should be allowed in the trunk definitions as well as DTLS (ok, I'm 
getting picky ;)).

I think the filtering trunk might have a limitation as it only allows
non-local domain parts in the Request URI. A basic functionality test
like an OPTIONS request should be able to test if the SIP proxy 
providing the filtering trunk itself is available. Therefore we need
a way to directly address the SIP entity the trunk runs on.

Regards,
  Hendrik

--
Hendrik Scholz
VoIP Systems Engineer

----------------------------------------------------------------------------
Telefon: + 49 (0) 431 90 20 552
Telefax: + 49 (0) 431 90 20 559
E-Mail: [email-masked]
Website:  www.freenet.de; www.mobilcom.de
----------------------------------------------------------------------------
freenet Cityline GmbH
Ein Unternehmen der freenet AG
Am Germaniahafen 1-7
24143 Kiel
----------------------------------------------------------------------------
Geschäftsführer: Eckhard Spoerr, Axel Krieger
Amtsgericht Kiel, HRB 6202

_______________________________________________
Sipping mailing list  https://www.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

---

From: "Sumit Garg" <[email-masked]>
Date: Thu, 13 Mar 2008 11:11:40 -0400

I like the mechanism identified in section 3 using Route headers to
identify SIP trunks.
Would it make sense to define this as an extension to RFC4904. It would
be useful if we could
use the same tgrp parameter in the Route header, to provide information
as desired in the
above draft.

Currently in Switch A to B to C to D call:

A----(tgrp-1)--->B----Contact(tgrp-1)---->C---(tgrp-2)--->D
                       R-URI (tgrp-2)

When B gets a call from A (on tgrp-1) and needs C to route it to D over
tgrp-2,
it would put tgrp-1 in its Contact and and tgrp-2 in the R-URI.

There is no way for C to identify what trunk on C the call is to be
handled on, i.e.
what feature set etc. is to be applied on this (i.e. Section 2.3 in the
draft kind of stuff).

The Route header could use the parameters in the RFC4904, for
consistency.

-Sumit

"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man."
-- George Bernard Shaw