Session manager adaptations 2

[mattKnight]

Hi All,

In simple terms, I have a SM with 3 entity links (1 each to 2 ACM systems and 1 to a conference server)
I have a digit conversion adaptation on the entity link to ACM 1 to adjust a 4 digit dialled number to a 7 digit station;
On the "Digit Conversion for Incoming Calls to SM" match 4 digits, strip 1, prefix destination number with 4 digits and SM then routes appropriately on the full 7 digits. This works ok

I also have a digit conversion adaptation on the entity link to ACM 1 to adjust a 7 digit orgination number to a 4 digit for presentation to other nodes in the network.
On the "Digit Conversion for Incoming Calls to SM" match 7 digits, strip 4, prefix originatio number with 1 digit

The second conversion works fine for calls between the 2 ACM systems (4 digit calling and 4 digit presentation) However teh conference server still sees the unmodified 7 digit presentation!

I can't see why - unless the conference server is using soemthing other than the P-Asserted-ID as the origination address! I haven't yet taken a traffic capture as that is not straightforward in this environment.

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[kyle555]

It sounds like you need an adaptation on egress calls from SM to your conferencing server.

Let's map out your scenario - I'm on CM1, I dial 4 digits (1234), match in UDP to AAR, get pitched to the SM trunk.

SM has a digit conversion adapter on ingress calls from that SIP entity. Match 1234, delete the "1", insert 4567.

4567234 now gets passed to SM's dial plan. Dial pattern 4567234 matches, to CM2 routing policy, to SIP entity CM2 as destination.

Question: where is 4567 stripped? Do you do it as an egress adaptation to CM2 "match 4567234, delete 4 leading digits, insert 2, result 2234?" or, do you handle it in CM2 on the incoming call handling treatment and do it there? Your post would seem to indicate the former example.

I would think you'd need to apply the same or a similar egress adaptation to your SIP entity for your conference server to match your 7 digits, and delete/insert as appropriate.

You can "traceSM" from the Session Manager command line, and you can also use "f" in there to filter by -u 1234 (user 1234) or -i 1.2.3.4 (ip address) and if you select all 3 options (SIP, something I can't remember, and PPM), the "something I can't remember" will show you the routing decisions and the application of the parameters and adaptations you've applied to lead to the result of the formulated SIP invite being shipped to your conferencing server.

Is it an Avaya conferencing server?

 

[mattKnight]

>It sounds like you need an adaptation on egress calls from SM to your conferencing server.

If that's the case, why don't I need one on the egress to CM2?

>Let's map out your scenario - I'm on CM1, I dial 4 digits (1234), match in UDP to AAR, get pitched to the SM trunk.
>SM has a digit conversion adapter on ingress calls from that SIP entity. Match 1234, delete the "1", insert 4567.

Not quite the correct scenario!
SM has a digit conversion adapter on ingress calls from that SIP entity. Route call on 1234 (as I don't want to modify dialed number) Match CLI 7654321, delete the 7654, insert 1 Hence call appears to come from 1321

In this scenario, calls from CM1 to CM2 show 1321 for origination as desired. However calls to Conference server show 7654321 as origination.

> I would think you'd need to apply the same or a similar egress adaptation to your SIP entity for your conference server to match your 7 digits, and delete/insert as appropriate.
The adaptation on the links serving CM2 and conference server *are* the same.

>Is it an Avaya conferencing server?
Yes MX5.2




Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[kyle555]

What dial pattern are you matching in SM to go from CM1 to CM2. What does a traceSM show you for the call processing?

 

[mattKnight]

>What dial pattern are you matching in SM to go from CM1 to CM2.
4 digit 3xxx or 4xxx

>What does a traceSM show you for the call processing?
I'm at home - I'll have to run this on Wednesday




Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[kyle555]

Sure, to be continued!

 

[mattKnight]

>I can't see why - unless the conference server is using something other than the P-Asserted-ID as the origination address

This appears to be the case!

I can see the invite packet to the conference server showing the P-Asserted-ID as being modified by the adaptation - i.e zxxx@sipdomain instead of yyyyxxx@sipdomain.

Thanks for your help!

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[redphone]

If you suspect it is matching on the From header rather than the PAI, then include fromto=true as a parameter in the adaptation.

From the 6.1 Release Notes:

A new adaptation module parameter ‘fromto’ has been
added. If you supply ‘fromto=true’ in the adaptation
module parameters field of an adaptation, then the
adaptation logic will be applied to the From and To
headers of a message

 

[mattKnight]

redphone

That's fixed my problem!

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.